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推荐 序 


在 阿里 巴巴 技术 发 展 初期 ， 伴 随 独 淘宝 业务 的 快速 发 展 ， 网 站 流量 
呈现 几何 级 增长 。 单 体 巨 无 霸 式 的 应 用 无 法 处 理 爆发 式 增长 的 流量 ， 阿 
里 内 部 从 业务 、 组 织 层面 进行 了 一 次 大 的 水 平 与 垂直 切 分 ， 拆 分 出 用 户 
中 心 、 商 品 中 心 、 交 易 中 心 、 评 价 中 心 等 平台 型 应 用 ， 分 布 式 电 商 系统 
的 骏 形 由 此 诞生 。 阿 里 的 消 轧 引擎 就 是 在 这 样 的 大 背景 下 诞生 的 ， 并 被 
应 用 于 各 个 应 用 系统 之 间 的 腊 步 解 看 和 前 峰 填 谷 。 


从 最 初 的 日 志 传 输 领 域 到 后 来 阿里 集团 全 维度 在 线 业 务 的 文 撑 ， 
RocketMQ 被 广泛 用 于 交易 、 数 据 同步 、 绥 存 同步 、IM 通 讯 、 流 计算 、 
IoT 等 场景 。 在 近 几 年 的 双 11 全 球 狂 欢 节 中 ，RocketMQ 以 万 亿 级 的 消息 
总 量 文 撑 了 全 集团 3000 多 个 应 用 ， 为 复杂 的 业务 场景 提供 了 系统 解 耦 、 
削 峰 填 谷 的 能 力 ， 保 障 了 核心 交易 链 路 消 上 流 转 的 低 延 迟 、 高 和 厨 吐 ， 为 
阿里 集团 大 中 人 台 的 稳定 性 发 挥 了 举足轻重 的 作用 。 


为 了 更 好 地 发 展 RocketMQ 社 区 生态 ，2016 年 双 11 前 后 ， 阿 里 巴巴 
将 RocketMQ 捐 赠 给 Apache 基 金 会 ， 吸 引 了 全 球 的 开源 爱好 者 参与 到 
RocketMQ 社 区 中 ， 并 于 2017 年 9 月 成 为 Apache 基 金 会 的 顶级 项 目 。 在 开 
源 社 区 的 帮助 下 ，RocketMQ 上 具备 了 对 接 主流 大 数据 流 计算 平台 、 离 在 
线 数据 处 理 以 及 对 接 存储 平台 的 能 力 。 


本 书 介绍 了 分 布 式 消息 中 间 件 RocketMQ 的 方方面面 ， 作 者 为 大 数 
据 领 域 的 技术 专家 ， 在 分 布 式 领域 具有 很 丰富 的 理论 积累 和 实战 经 验 。 
书 如 其 人 ， 书 中 各 章节 尽 展 实战 经 验 ， 应 丁 解 牛 般 剖 析 了 Apache 
RocketMQ 的 原理 和 架构 设计 。 本 书 深 入 浅 出 地 分 析 了 RocketMQ 的 整体 
架构 ， 分 享 了 部 署 和 运 维 的 经 验 ， 涵 盖 RocketMQ 的 核心 特性 高 可 
用 、 高 可 靠 机 制 ， 以 及 开源 生态 等 。 

本 书 作为 国内 首 本 全 面 解析 Apache RocketMQ 的 书籍 ， 对 于 希望 了 


解 RocketMQ 拉 术 内 融 ， 以 及 想 要 向 握 分 布 式 系 统 设计 理念 的 拉 术 人 员 
来 说 的 确 不 容错 过 。 




















周 新 宇 ，Apache RocketMQ 项 目 管理 委员 会 成 员 
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几 年 前 在 做 一 个 项 目的 时 候 ， 若 需要 用 到 消息 队列 ， 简 单调 研一 下 
就 会 决定 用 Kafka， 因 为 当时 还 不 知道 有 RocketMQ。 在 我 加 入 阿里 后 ， 
当时 有 个 项 目 需 要 用 到 消息 中 间 件 ， 试 用 了 RocketMQ， 发 现 阿 里 开源 
的 消息 中 间 件 性 能 非常 强大 ， 但 是 上 手 有 点 费劲 ， 因 为 现 有 文档 多 是 零 
零散 散 的 博文 。 在 没有 合适 文档 指导 的 情况 下 ， 对 系统 中 用 到 的 
RocketMQ 模 块 心里 没 底 ， 系 统 偶尔 出 现 异常 时 总 会 束手无策 ， 需 要 通 
过 查看 很 多 源码 ， 才 能 保证 系统 的 稳定 运行 。 


测 悉 RocketMQ 以 后 ， 我 发 现 它 是 一 球 非 徊 优 夯 的 中 间 件 产品 ， 可 
以 确保 不 于 消息 ， 而 且 效 率 很 高 。 同 时 因为 它 是 用 Java 开 发 的 ， 所 以 修 
改 起 来 比较 容易 。 


在 阿里 内 部 ，RocketMQ 很 好 地 服务 了 集团 大 大 小 小 上 千 个 应 用 ， 
在 每 年 的 双 十 一 当天 ， 更 有 不 可 思议 的 万 亿 级 消息 通过 RocketMQ 流 转 
(在 2017 年 的 双 11 当 天 ， 整 个 阿里 巴巴 集团 通过 RocketMQ 流 转 的 线 上 
消息 达到 了 万 亿 级 ， 峰 值 TPS 达 到 5600 万 ) ， 在 阿里 大 中 人 台 策 略 上 发 挥 
着 举足轻重 的 作用 。 所 以 如 果 有 合适 的 参考 文档 ，RocketMQ 会 被 更 多 
人 接受 和 使 用 ， 让 更 多 人 不 必 重 复 造 “轮子 ”。 


我 做 了 很 多 年 开发 ， 在 学 校 课 本 上 学 的 开发 知识 有 限 ， 大 多 数 是 通 
过 看 书 和 上 网 学 到 的 ， 其 中 很 多 优秀 的 文章 对 上 自己 帮助 很 大 。 上 所 以 我 很 
希望 能 用 这 本 书 回馈 技术 社区 中 有 需要 的 开发 者 们 。 


动笔 写 这 本 书 前 ， 我 系统 地 阅读 了 RocketMQ 的 源码 ， 有 些 理 解 不 
够 透彻 的 地 方 请 教 了 阿里 RocketMQ 开 发 团队 的 同事 ， 然 后 也 总 结 了 上 自 
己 多 年 实际 工作 中 的 一 些 经 验 。 和 希望 这 本 书 能 简明 扼要 地 说 清楚 
RocketMQ 的 使 用 方法 和 核心 原理 。 
































读者 对 象 





-希望 学 习 分 布 式 系统 或 分 布 式 消 恩 队列 的 开发 人 员 。 
m 服务 端 系 统 开 及 者 ， 他 们 可 以 借助 高 质量 中 间 件 来 提高 开发 效 








:软件 架构 师 ， 他 们 可 以 通过 消息 队列 优化 复杂 系统 的 设计 。 
本 书 特色 


本 书 系 统 地 介绍 了 RocketMQ 这 款 优秀 的 分 布 式 消 息 队 列 软件 ， 通 
过 阅读 本 书 ， 读 者 可 以 快速 把 RocketMQ 应 用 到 自己 的 项 目 中 ， 也 可 以 
通过 更 改 源 码 定制 符合 自身 业务 的 消息 中 间 件 。 


如 何 阅读 本 书 


本 书 分 为 两 大 部 分 : 


第 一 部 分 是 RocketMQ 实 战 ， 包 括 第 1 一 8 章 。 这 是 本 书 的 主体 内 
容 ， 可 帮助 读者 快速 用 好 RocketMQ 这 个 分 布 式 消 息 队 列 。 


这 部 分 是 按照 由 浅 入 深 的 方式 撰写 的 ， 为 了 让 读者 快速 上 手 ， 首 先 
介绍 了 搭建 一 个 简单 RocketMQ 和 集群 的 方法 ， 以 此 来 发 送 和 接收 消息 ; 
然后 详细 介绍 了 如 何 用 好 Consumer 和 Producer， 如 何 选 择 合适 的 类 以 及 
进行 参数 设置 ， 再 进一步 根据 应 用 ， 说 明 如 何 让 RocketMQ 在 各 种 异常 
情况 下 保持 稳定 可 靠 ， 以 及 如 何 增 大 RocketMQ 的 吞吐 量 ， 从 而 在 单位 
时 间 内 处 理 更 多 的 消息 。 


第 二 部 分 是 源码 分 析 ， 包 括 第 9 一 13 章 。 当 读者 有 特殊 的 业务 需 
求 ， 需 要 更 改 或 扩展 RocketMQ 现 有 功能 的 时 候 ， 这 部 分 内 容 能 帮助 读 
者 快速 熟悉 源码 ， 找 到 要 下 手 更 改 的 地 方 ， 快 速 实现 想 要 的 功能 。 


这 部 分 也 适合 想 通 过 源码 ， 深 入 学 习 消 轧 队 列 的 读者 阅读 。 学 习 别 
人 优秀 的 代码 是 提升 目 己 技术 水 平 的 一 条 有 效 途 径 。 











ER AL SC FF 


由 于 水 平 有 限 ， 编 写 时 间 人 仓促， 书 中 难免 会 出 现 一 些 错误 或 者 不 准 
确 的 地 方 ， 奶 请 读者 批评 指正 。 有 任何 的 意见 或 建议 ， 都 可 以 通过 邮箱 
rocketmqqa@D163.com 和 我 联系 ， 真 挚 期 竺 你 的 反馈 。 
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HIE REAN 


本 章 可 以 让 读者 了 解 RocketMQ 和 分 布 式 消 息 队 列 的 功能 ， 然 后 拱 
建 好 单机 版 的 消 恩 队列 ， 进 而 能 够 友 送 并 接收 简单 的 消 乱 。 


1.1 消息 队列 功能 介绍 


简单 来 说 ， 消 轧 队 列 藉 是 基础 数据 结构 谍 程 里 “先进 先 出 ”的 一 种 数 
据 结 构 ， 但 是 如 果 要 消除 单 点 故障 ， 保 证 消 恩 传输 的 可 徘 性 ， 并 且 还 能 
应 对 大 流量 的 冲击 ， 对 消 娠 队列 的 要 求 就 很 蜗 了 。 现 在 互联 网 “ 微 架 
构 ” 模 式 兴 起 ， 原 有 大 型 集中 式 的 I 服务 因为 各 种 浆 端 ， 通 当 被 分 拆 成 
细 粒 度 的 多 个 “微服 务 ”， 这 些微 服务 可 以 在 一 个 局 域 网 内 ， 也 可 能 路 机 
房 部 着。 一 方面 对 服务 之 间 松 耘 合 的 要 求 越 来 越 遍 ， 忆 一 方面 ， 服 务 之 
间 的 联系 却 越 来 越 紧 密 ， 对 通信 质量 的 要 求 也 越 来 越 高 。 分 布 式 消息 队 
列 可 以 提供 应 用 解 稍 、 流 量 消 峰 、 消 息 分 发 等 功能 ， 已 经 成 为 大 型 互联 
网 服务 架构 里 标 配 的 中 间 件 。 








1.1.1 应 用 解 耦 


复杂 的 应 用 里 会 存在 多 个 子 系统 ， 比 如 在 电 商 应 用 中 有 订单 系统 、 
库存 系统 、 物 流 系 统 、 支 付 系统 等 。 这 个 时 候 如 果 各 个 子 系统 之 间 的 灰 
合 性 太 高 ， 整 体系 统 的 可 用 性 融会 大 幅 降 低 。 多 个 低 错误 率 的 子 系统 强 
耦合 在 一 起 ， 得 到 的 是 一 个 高 错误 率 的 整体 系统 。 


以 电 商 应 用 为 例 ， 用 尸 创建 订单 后 ， 如 果 耦 合 调用 库存 系统 、 物 流 
系统 、 文 付 系统 ， 任 何 一 个 子 系统 出 了 故障 或 者 因为 升级 等 原因 和 暂时 不 
可 用 ， 痢 会 造成 下 单 操作 和 异常， 影响 用 户 使 用 体验 。 


如 图 1-1 所 示 ， 当 转变 成 基于 消息 队列 的 方式 后 ， 系 统 可 用 性 就 高 
多 了 ， 比 如 物流 系统 因为 发 生 故 障 ， 需 要 儿 分 钟 的 时 间 来 修复 ， 在 这 几 
分 钟 的 时 间 里 ， 物 流 系统 要 处 理 的 内 容 被 缓存 在 消 妃 队列 里 ， 用 户 的 下 
单 操作 可 以 正 第 完成 。 当 物流 系统 恢复 后 ， 补 充 处 理 存 储 在 消息 队列 里 
的 订单 信息 即 可 ， 终 端 用 户 感 知 不 到 物流 系统 发 生 过 几 分 钟 的 故障 。 
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1.1.2 MEMI 





每 年 的 双 十 一 ， 淘 至 的 很 多 活动 都 在 0 点 的 时 候 开 局， 大 部 分 应 用 
系统 流量 会 在 瞬间 猛 增 ， 这 个 时 候 如 果 没 有 绥 冲 机 制 ， 不 可 能 承受 住 短 
时 大 流量 的 冲击 。 通 过 利用 消 轧 队列 ， 把 大 量 的 请 求 暂 存 起 来 ， 分 散 到 
相对 长 的 一 段 时 间 内 处 理 ， 能 大 大 提高 系统 的 稳定 性 和 用 户 体验 。 


举 个 例子 ， 如 果 订 单 系统 每 秒 最 多 能 处 理 一 万 次 下 单 ， 这 个 处 理 能 
力 应 对 正常 时 段 的 下 单 是 绰绰有余 的 ， 正 钊 时 段 我 们 下 单 后 一 秒 内 吏 能 
返回 结果 。 在 双 十 一 零点 的 时 候 ， 如 果 没 有 消息 队列 这 种 缓冲 机 制 ， 为 
了 保证 系统 稳定 ， 只 能 在 订单 超过 一 万 次 后 就 不 允许 用 户 下 单 了 ; 如 果 
有 消 妃 队列 做 缓冲 ， 我 们 可 以 取消 这 个 限制 ， 把 一 秒 内 下 的 订单 分 散 成 
一 段 时 间 来 处 理 ， 这 时 有 些 用 户 可 能 在 下 单 后 十 儿 秒 才能 收 到 下 单 成 功 
的 状态 ， 但 是 也 比 不 能 下 单 的 体验 要 好 。 


使 用 消息 队列 进行 流量 消 峰 ， 很 多 时 候 不 是 因为 能 力 不 够 ， 而 是 出 
于 经 济 性 的 考量 。 比 如 有 的 业务 系统 ， 流 量 最 高 峰 也 不 会 超过 一 万 
QPS， 而 平时 只 有 一 干 左右 的 QPS。 这 种 情况 下 我 们 就 可 以 用 个 普通 性 
能 的 服务 器 (只 支持 一 千 左 右 的 QPS 就 可 以 )， 然 后 加 个 消息 队列 作为 
高 峰 期 的 缓冲 ， 无 须 花 大 笔 资 金 部 区 能 处 理 上 万 QPS 的 服务 占 。 





11.3 消息 分 发 


在 大 数据 时 代 ， 数 据 对 很 多 公司 来 说 就 像 金 矿 ， 公 司 需要 依赖 对 数 
据 的 分 析 ， 进 行 用 户 画像 、 精 准 推送 、 流 程 优 化 等 各 种 操作 ， 并 且 对 处 
理 的 实时 性 要 求 越 来 越 高 。 数 据 是 不 断 产生 的 ， 各 个 分 析 团 队 、 算 法 团 
队 都 要 依赖 这 些 数据 来 进行 工作 ， 这 个 时 候 有 个 可 持久 化 的 消息 队列 融 
非常 重要 。 数 据 的 产生 方 只 需要 把 各 目的 数据 写 入 一 个 消 轧 队列 即 可 ， 
数据 使 用 方 根据 各 上 自 需求 订阅 感 兴 趣 的 数据 ， 不 同 数据 团队 所 订阅 的 数 
据 可 以 重复 也 可 以 不 重复 ， 互 不 干扰 ， 也 不 必 和 数 据 产 生 方 关联 。 


如 图 1-2 所 示 ， 各 个 子 系统 将 日 志 数 据 不 停 地 写 入 消 妃 队列 ， 不 同 
的 数据 处 理 系统 有 各 目的 Offset， 互 不 影响 。 甚 至 茶 个 团队 处 理 完 的 结 
打数 据 也 可 以 写 入 消 轧 队列 ， 作 为 数据 的 产生 方 ， 供 其 他 团队 使 用 ， 避 
免 重 复 计 算 。 在 大 数据 时 代 ， 消 乱 队 列 已 经 成 为 数据 处 理 系统 不 可 或 缺 


的 一 部 分 。 


除了 上 面 列 出 的 应 用 解 秋 、 流 量 消 峰 、 消 妃 分 友 等 功能 外 ， 消 息 队 
列 还 有 保证 最 终 一 致 性 、 方 便 动 态 扩容 等 功能 。 
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图 1-2 ” 消 妃 队列 的 消息 分 发 功能 


1.2 ”RocketMQ 傈 介 


阿里 的 消息 中 间 件 有 很 长 的 历史 ， 从 2007 年 的 Notify 到 2010 年 的 
Napoli，2011 年 升级 后 改 为 MetaQ ， 然 后 到 2012 年 开始 做 RocketMQ， 
RocketMQ 使 用 Java 语 言 开 发 ， 于 2016 年 开源 。 第 一 代 的 Notify 主 要 使 用 
了 推 模型 ， 解 决 了 事务 消息 ; 第 二 代 的 MetaQ 主 要 使 用 了 拉 模 型 ， 解 决 
了 顺序 消息 和 海量 堆积 的 问题 。RocketMQ 基 于 长 轮 询 的 拉 取 方式 ， 兼 
有 两 者 的 优点 。 


每 一 次 产品 迭代 ， 都 吸取 了 之 前 的 经 验 教 训 ， 目 前 RocketMQ 已 经 
成 为 Apache 顶 级 项 目 。 在 阿里 内 部 ，RocketMQ 很 好 地 服务 了 集团 大 大 
小 小 上 千 个 应 用 ， 在 每 年 的 双 十 一 当天 ， 更 有 不 可 思议 的 万 亿 级 消息 通 
过 RocketMQ 流 转 ( 在 2017 年 的 双 十 一 当天 ， 整 个 阿里 巴巴 集团 通过 
RocketMQ 流 转 的 线 上 消息 达到 了 万 亿 级 ， 峰 值 TPS 达 到 5600 万 ) ， 在 阿 
里 大 中 台 策 略 上 发 挥 着 举足轻重 的 作用 。 


此 外 ，RocketMQ 是 使 用 Java 语 言 开 发 的 ， 比 起 Kafka 的 Scala 语 言 和 
RabbitMQ 的 Erlang 语 言 ， 更 容易 找到 技术 人 员 进 行 定制 开发 。 














1.3 ”快速 上 手 RocketMQ 


本 节 介 绍 如 何 安装 配置 单机 版 的 RocketMQ， 以 及 简单 地 收发 消 
息 。 读 者 也 可 以 参考 RocketMQ 官 网 的 说 明文 档 。 


1.3.1 RocketMQ 的 下 载 、 安 装 和 配置 


RocketMQ 的 Binary 版 是 一 些 编译 好 的 jar 和 辅助 的 shell 脚 本 ， 可 以 直 
接 从 官网 找到 下 载 链接 (http://rocketmq.apache.org/dowloading/releases/ 
) ， 也 可 以 下 载 源码 自己 编译 。 


系统 要 求 : 64bit 的 Linux、Unix 或 Mac。Java 版 本 大 于 等 于 JDK1.8。 
如 果 需 要 从 GitHub 上 下 载 源码 和 编译 的 话 ， 需 要 安装 Maven 3.2.x 利 
Git. 





RocketMQ 当 前 的 最 新 版 本 是 4.2.0， 下 面 以 Binary 版 本 为 例 说 明 如 何 
快速 使 用 : 





> unzip rocketmq-all-4.2.0-bin-release.zip -d ./rocketmq-all-4.2.0-binls 
> cd rocketmq-all-4.2.0-bin/ 





里 面 含有 以 下 内 容 : 





LICENSE NOTICE README.md benchmark/ bin/ conf/ lib/ 





LICENSE、NOTICE 和 README.md 包 括 一 些 版 权 声明 和 功能 说 明 
信息 ; benchmark 里 包括 运行 banchmark 程 序 的 shell 脚 本 ; bin 文件 夹 里 含 
有 各 种 使 用 RocketMQ 的 shell 脚 本 〈Linux 平 台 ) 和 cmd 脚 本 (Windows 
平台 ) ， 比 如 常用 的 启动 NameServer 的 脚本 mqnamesrv， 启 动 Broker 的 
脚本 mqbroker， 集 群 管理 脚本 mqadmin 等 ;conf 文 件 夹 里 有 一 些 示 例 配 
置 文件 ， 包 括 三 种 方式 的 broker 配 置 文件 、logback 日 志 配 置 文件 等 ， 用 
户 在 写 配置 文件 的 时 候 ， 一 般 基 于 这 些 示 例 配置 文件 ， 加 上 上 自己 特殊 的 
需求 即 可 ;lib 文件 夹 里 包括 RocketMQ 各 个 模块 编译 成 的 jar 包 ， 以 及 
RocketMQ 依 赖 的 一 些 jar 包 ， 比 如 Netty、commons-lang、FastJSON 等 。 








1.3.2 ”局 动 消息 队列 服务 


启动 单机 的 消息 队列 服务 比较 简单 ， 不 需要 写 配 置 文件 ， 只 需要 依 
次 启动 本 机 的 NameServer 和 Broker 即 可 。 





启动 NameServer: 





> nohup sh bin/mqnamesrv & 
> tail -f ~/Logs/rocketmqLogs/namesrv.Log 
The Name Server boot success... 





启动 Broker: 





> nohup sh bin/mqbroker -n localhost:9876& 
> tail -f ~/Logs/rocketmqLogs/broker.Log 
The broker[%s, 192.168.0.233:10911] boot success... 





1.3.3 Aart RIK E 


为 了 快速 展示 发 送 和 接收 消息 ， 本 节 展 示 的 是 用 命令 行 发 送 和 接收 
消息 ， 实 际 上 就 是 运行 号 好 的 demo 程 序 ， 后 续 我 们 可 以 参考 这 些 demo 
来 写 目 己 的 发 送 和 接收 程序 。 


运行 示例 程序 ， 发 送 和 接收 消息 : 








> export NAMESRV_ADDR=localhost :9876 
> sh bin/tools.sh org.apache.rocketmq. E quickstart .Producer 


SendResult [sendStatus=SEND_OK, msgId= .. 


> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer 
ConsumeMessageThread_%d Receive New Messages: [MessageExt... 





13.4 关闭 消息 队列 


消息 队列 被 局 动 后 ， 如 果 不 主 动 关闭 ， 则 会 一 ETE Ag 了 于， 占用 
系统 资源 。 我 们 有 专门 用 来 关闭 NameServer 和 Broker 的 命令 。 


关闭 NameServer 和 Broker: 





> sh bin/mqshutdown broker 
The mqbroker(36695) is running. 
Send shutdown request to mabroker (36695) OK 


> sh bin/mqshutdown namesrv 
The mqnamesrv(36664) is running... 
Send shutdown request to mqnamesrv(36664) OK 





藉 喜 ， 现 在 你 已 经 能 够 使 用 RocketMQ 发 送 并 接收 消息 了 ， 使 用 消 
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14 本 章 小 结 


本 章 介绍 了 消息 队列 的 功能 ， 以 及 RocketMQ 这 个 消息 队列 从 阿里 
诞生 的 历史 。 然 后 基于 快速 上 手 的 目的 ， 本 章 直 接 给 出 了 一 些 命令 示 
例 ， 读 者 跟着 操作 即 可 快速 局 动 一 个 RocketMQ 服 务 ， 并 且 可 以 党 试 发 
送 和 接收 简单 的 消息 。 有 了 本 章 的 初步 体验 后 ， 下 一 章 将 介绍 如 何在 生 
产 环境 使 用 RocketMQ 。 


第 2 草 ”生产 环境 下 的 配置 和 使 用 


本 章 的 目的 是 带领 读者 快速 将 RocketMQ 应 用 到 生产 环境 中 ， 因 此 
不 会 探究 原理 和 细节 。 本 章 会 先 介绍 RocketMQ 的 各 个 角色 ， 然 后 介绍 
如 何 搭建 一 个 高 可 用 的 分 布 式 消息 队列 集群 ， 以 及 RocketMQ 的 
Consumer 和 了 Producer 的 使 用 方法 与 常用 命令 。 





2.1 RocketMQ 各 部 分 角色 介绍 


RocketMQ 由 四 部 分 组 成 ， 先 来 直观 地 了 解 一 下 这 些 角色 以 及 各 自 
的 功能 。 分 布 式 消息 队列 是 用 来 高 效 地 传输 消息 的 ， 它 的 功能 和 现实 生 
活 中 的 邮局 收发 信件 很 类 似 ， 我 们 类 比 地 说 一 下 相应 的 模块 。 现 实生 活 
中 的 邮政 系统 要 正常 运行 ， 离 不 开 下 面 这 四 个 角色 ， 一 是 发 信者 ， 二 是 
收 信者 ， 三 是 负责 暂 存 、 传 输 的 邮局 ， 四 是 负责 协调 各 个 地 方 邮局 的 管 
理 机 构 。 对 应 到 RocketMQ 中 ， 这 四 个 角色 就 是 Producer、Consumer、 
Broker 和 NameServer。 








启动 RocketMQ 的 顺序 是 先 启动 NameServer， 再 启动 Broker， 这 时 
候 消 息 队 列 已 经 可 以 提供 服务 了 ， 想 发 送 消息 就 使 用 Producer 来 发 送 ， 
想 接 收 消息 就 使 用 Consumer 来 接收 。 很 多 应 用 程序 既 要 发 送 ， 叉 要 接 
收 ， 可 以 启动 多 个 Producer 和 Consumer 来 发 送 多 种 消息 ， 同 时 接收 多 种 


AN ba 
消息 。 


为 了 消除 单 点 故障 ， 增 加 可 靠 性 或 增 大 吞吐 量 ， 可 以 在 多 台 机 器 上 
部 署 多 个 NameServer 和 Broker， 为 每 个 Broker 部 署 一 个 或 多 个 Slave。 

















图 2-1 RocketMQ 各 个 角色 间 关 系 


了 解 了 四 种 角色 以 后 ， 再 介绍 一 下 Topic 和 Message Queue 这 两 个 名 
词 。 一 个 分 布 式 消 轧 队列 中 间 件 部 团 好 以 后 ， 可 以 给 很 多 个 业务 提供 服 
务 ， 同 一 个 业务 也 有 不 同类 型 的 消息 要 投递 ， 这 些 不 同类 型 的 消息 以 不 


同 的 Topic 名 称 来 区 分 。 所 以 发 送 和 接收 消息 前 ， 先 创建 Topic， 针 对 某 
个 Topic 发 送 和 接收 消息 。 有 了 Topic 以 后 ， 还 需要 解决 性 能 问题 。 如 果 
一 个 Topic 要 发 送 和 接收 的 数据 量 非常 大 ， 需 要 能 文 持 增加 并 行 处 理 的 
机 器 来 提高 处 理 速度 ， 这 时 候 一 个 Topic 可 以 根据 需求 设置 一 个 或 多 个 
Message Queue, Message Queue 类 似 分 区 或 Partition。Topic 有 了 多 个 
Message Queue 后 ， 消 息 可 以 并 行 地 癌 各 个 Message Queue 发 送 ， 消 费 者 
也 可 以 并 行 地 从 多 个 Message Queue 读 取消 息 并 消费 。 





2.2 ”多 机 集群 配置 和 部 署 


本 节 将 说 明 如 何 只 用 两 台 物 理 机 ， 搭 建 出 双 主 、 双 从 、 无 单 点 故障 
的 高 可 用 RocketMQ 和 集群 。 假 设 这 两 台 物 理 机 的 IP 分 别 是 192.168.100.131 
和 192.168.100.132。 


2.2.1 局 动 多 个 NameServer 和 Broker 


首先 在 这 两 台 机 器 上 分 别 启动 NameServer (nohup sh bin/mqnamesrv 
&) ， 这 样 我 们 束 得 到 了 一 个 无 单 点 的 NameServer 服 务 ， 服 务 地 址 
是 “192.168.100.131: 9876; 192.168.100.132: 9876”. 


然后 局 动 Broker， 每 台 机 器 上 都 要 分 别 启动 一 个 Master 角 色 的 
Broker 和 一 个 Slave 角 色 的 Broker， 并 互 为 主 备 。 可 以 基于 RocketMQ 目 
带 的 示例 配置 文件 写 自 己 的 配置 文件 (示例 配置 文件 在 conf/2m-2s-sync 
目录 下 ) 。 


1) 192.168.100.131 机 器 上 Master Broker 的 配置 文件 : 





namesrvAddr=192.168.100.131:9876; 192.168.100.132:9876 
brokerClusterName=DefaultCluster 

brokerName=broker-a 

brokerId=0 

deletewhen=04 

fileReservedTime=48 

brokerRole=SYNC_MASTER 

flushDiskType=ASYNC_FLUSH 

listenPort=10911 
storePathRootDir=/home/rocketmq/store-a 





2) 192.168.100.132 机 器 上 Master Broker 的 配置 文件 : 





namesrvAddr=192.168.100.131:9876; 192.168.100.132:9876 
brokerClusterName=DefaultCluster 

brokerName=broker-b 

brokerId=0 

deletewhen=04 

fileReservedTime=48 

brokerRole=SYNC_MASTER 

flushDiskType=ASYNC_FLUSH 

listenPort=10911 
storePathRootDir=/home/rocketmg/store-b 





3) 192.168.100.131 机 器 上 Slave Broker 的 配置 文件 : 





namesrvAddr=192.168.100.131:9876; 192.168.100.132:9876 
brokerClusterName=DefaultCluster 

brokerName=broker-b 

brokerId=1 


deletewhen=04 

fileReservedTime=48 

brokerRole=SLAVE 
flushDiskType=ASYNC_FLUSH 
listenPort=11011 
storePathRootDir=/home/rocketmg/store-b 





4) 192.168.100.132 机 器 上 Slave Broker 的 配置 文件 : 





namesrvAddr=192.168.100.131:9876; 192.168.100.132:9876 
brokerClusterName=DefaultCluster 

brokerName=broker-a 

brokerId=1 

deletewhen=04 

fileReservedTime=48 

brokerRole=SLAVE 

flushDiskType=ASYNC_FLUSH 

listenPort=11011 
storePathRootDir=/home/rocketmg/store-a 





然后 分 别 使 用 如 下 命令 启动 四 个 Broker: 





nohup sh ./bin/mqbroker -c config_file & 





这 样 一 个 高 可 用 的 RocketMQ 集 群 就 搭建 好 了 ， 还 可 以 在 一 台 机 器 
上 启动 rocketmq-console， 比 如 在 192.168.100.131 上 启动 RocketMQ- 
console， 然 后 在 浏览 器 中 输入 地 址 192.168.100.131: 8080， 这 样 就 可 以 
可 视 化 地 查看 集群 状态 了 。 


2.2.2 ”配置 参数 介绍 


本 节 将 逐个 介绍 Broker 配 置 文件 中 用 到 的 参数 含义 : 

1) namesrvAddr=192.168.100.131: 9876; 192.168.100.132: 9876 
NamerServer 的 地 址 ， 可 以 是 多 个 。 

2) brokerClusterName=DefaultCluster 


Cluster 的 地 址 ， 如 果 集 群 机 器 数 比 较 多 ， 可 以 分 成 多 个 Cluster， 
个 Cluster 供 一 个 业务 群 使 用 。 


3) brokerName=broker-a 


Broker 的 名 称 ，Master 和 Slave 通 过 使 用 相同 的 Broker 名 称 来 表明 相 
互 关 系 ， 以 说 明基 个 Slave 是 哪个 Master 的 Slave。 


4) brokerId=0 


一 个 Master Borker 可 以 有 多 个 Slave，0 表 示 Master， 大 于 0 表示 不 同 
Slave 的 ID。 





5) fileReservedTime=48 
在 磁盘 上 保存 消息 的 时 长 ， 单 位 是 小 时 ， 自 动 删除 超时 的 消息 。 
6) deleteWhen=04 


与 fleReservedTime 参 数 呼应 ， 表 明 在 几 点 做 消息 删除 动作 ， 默 认 值 
OAR ANIA o 





7) brokerRole=SYNC_MASTER 


brokerRole 有 3 种 : SYNC MASTER, ASYNC_ MASTER, 
SLAVE。 关 键 词 SYNC 和 ASYNC 表 示 Master 和 Slave 之 间 同 步 消 息 的 机 
制 ，SYNC 的 意思 是 当 Slave 和 和 Master 消息 同步 完成 后 ， 再 返回 发 送 成 功 





的 状态 。 
8) flushDiskType=ASYNC_FLUSH 


flushDiskType 表 示 刷 盘 策 略 ， 分 为 SYNC_FLUSH 和 
ASYNC_FLUSH 两 种 ， 分 别 代 表 同 步 刷 盘 和 有 异步 刷 盘 。 同 步 刷 盘 情况 
下 ， 消 息 真 正 写 入 磁盘 后 再 返回 成 功 状态 ; 异步 刷 盘 情况 下 ， 消 轧 写 入 
page_cache 后 就 返回 成 功 状态 。 


9) listenPort=10911 


Broker 监 听 的 端口 号 ， 如 果 一 台 机 器 上 局 动 了 多 个 Broker， 则 要 设 
置 不 同 的 端口 号 ， 避 免 冲 突 。 


10) storePathRootDir=/home/rocketmd/store-a 
存储 消息 以 及 一 些 配置 信息 的 根 目录 。 


这 些 配置 参数 ， 在 Broker 局 动 的 时 候 生 效 ， 如 果 启 动 后 有 更 改 ， 要 
重启 Broker。 现 在 使 用 云 服 务 或 多 网 卡 的 机 喜 比 较 普 志 ，Broker 上 自动 探 
测 获 得 的 jp 地 址 可 能 不 符合 要 求 ， 通 过 brokerIP1=47.98.41.234 这 样 的 配 
置 参 数 ， 可 以 设置 Broker 机 器 对 外 暴露 的 ip 地 址 。 





2.3 ”用 送 /接收 消息 示例 


可 以 用 上 自己 熟悉 的 开发 工具 创建 一 个 Java 项 目 ， 加 入 RocketMQ 
Client 包 的 依赖 ， 用 代码 清单 2-1 的 内 容 发 送 消息 ， 这 个 示例 代码 是 以 
Sync 方式 及 送 消息 的 。 


代码 清单 2-1 Producer 示 例 程序 





public class SyncProducer { 
public static void main(String[] args) throws Exception { 
//Instantiate with a Producer group name. 
DefaultMQProducer Producer = new 
DefaultMQProducer ("please_rename_unique_group_name") ; 
producer.setNamesrvAddr ("192.168.100.131:9876"); 
//Launch the instance. 
Producer.start(); 
for (int i = 0; i < 100; i++) { 
//Create a Message instance, specifying Topic, tag and Message body. 
Message msg = new Message("TopicTest" /* Topic */, 
"TagA" j* Tag ES 
("Hello Rocke ENO” ”十 
i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */ 





); 

//Call send Message to deliver Message to one of brokers. 
SendResult sendResult = Producer .send(msg); 
System.out.printf("%s%n", sendResult); 


//Shut down once the Producer instance is not longer in use. 
Producer .shutdown(); 





主要 流程 是 : 创建 一 个 DefaultMQProducer 对 象 ， 设 置 好 GroupName 
和 NameServer 地 址 后 启动 ， 然 后 把 待 发 送 的 消息 拼装 成 Message 对 象 ， 
(EH Producer K Rik. eR RAAT GA, tte ES 
DefaultMQPush-Consumer 类 实现 的 消费 者 程序 ， 如 代码 清单 2-2 所 示 。 


代码 清单 2-2 ”Consumer 示例 程序 





Z= 
* Instantiate with specified Consumer group name. 
*/ 
DefaultMQPushConsumer Consumer = new DefaultMQPushConsumer ("please rename tc 
/* 
* Specify name server addresses. 


Consumer .setNamesrvAddr ("192.168.249.47:9876"); 
/* 


* Specify where to start in case the specified Consumer group is a brand ne 
i 
Consumer . setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_FIRST_OFFSET); 
//Consumer .setMessageModel (MessageModel.BROADCASTING) ; 
/* 
* Subscribe one more more Topics to consume. 
ef 
Consumer.subscribe("TopicTest”, "*"); 
/* 
* Register callback to execute on arrival of Messages fetched from brokers 
ee 
Consumer .registerMessageListener(new MessageListenerConcurrently() { 
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, 
System.out.printf(Thread.currentThread().getName() + " Receive New 下 
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; 


Launch the Consumer instance. 
*/ 
Consumer.start(); 





Consumer 或 Producer 都 必须 设置 GroupName、NameServer 地 址 以 及 
端口 号 。 然 后 指明 要 操作 的 Topic 名 称 ， 最 后 进入 发 送 和 接收 逻辑 。 


24 常用 管理 命令 


MQAdmin 是 RocketMQ 目 带 的 命令 行 管理 工具 ， 在 bin 目 录 下 ， 运 行 
mqadmin 即 可 执行 。 使 用 mqadmin 命 令 ， 可 以 进行 创建 、 修 改 Topic， 更 
新 Broker 的 配置 信息 ， 查 询 特 定 消息 等 各 种 操作 。 本 节 将 介绍 几 个 常用 


的 命令 。 
1. 创 建 /修改 Topic 
消息 的 发 送 和 接收 都 要 有 对 应 的 Topic， 需 要 向 某 个 Topic 发 送 或 接 


收 消息 ， 所 以 在 正式 使 用 RocketMQ 进 行 消息 发 送 和 接收 前 ， 要 先 创建 
Topic， 创 建 Topic 的 指令 是 updateTopic， 表 2-1 列 出 了 支持 的 参数 。 











表 2-1 updateTopic 






Broker 地 址 ，Topic 所 在 的 Broker(192.168.0.1:10911) 






( 续 ) 
参数 说 明 
Cluster 名 称 ， 表 示 Topic 创建 在 该 集群 (集群 可 通过 clusterList 
aC 如 果 -b 为 空 ， 则 必 填 | 查询 )， 如 果 集 群 中 有 多 个 master 角色 的 Broker， 默 认 在 每 个 


Broker 上 创建 8 个 读 写 队列 
打印 帮助 


= NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876;192.168.0.2: 
JE 
9876 
-p 指定 新 Topic 的 权限 限制 ，(2|416), [2:W 4:R; 6:RW] 
aT BOAT GROW 8) 
TEWI ORIN 8 ) 
IE 


-W 


-t Topic 名 称 


2. 删 除 Topic 


与 创建 /修改 Topic 对 应 的 是 删除 Topic， 把 RocketMQ 系 统 中 不 用 的 
Topic 彻 底 清 除 ， 指 令 是 deleteTopic， 表 2-2 列 出 了 支持 的 参数 。 


表 2-2 deleteTopic 


参数 是 否 必 填 说 明 
-C Cluster 名 称 ， 要 删除 的 Topic 所 在 的 集群 
-h A 打印 帮助 


要 NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876: 192.168.0. 
-n JE 2:9876 


3. 创 建 /修改 订阅 组 


订阅 组 在 提高 系统 的 高 可 用 性 和 吞吐 量 方面 扮演 着 重要 的 角色 ， 比 
如 用 Clustering 模 式 消 费 一 个 Topic 里 的 消息 内 容 时 ， 可 以 启动 多 个 消费 
者 并 行 消费 ， 每 个 消费 者 只 消费 Topic 里 消息 的 一 部 分 ， 以 此 提高 消费 
速度 ， 这 个 时 候 就 是 通过 订阅 组 来 指明 哪些 消费 者 是 同一 组 ， 同 一 组 的 
消费 者 共同 消费 同一 个 Topic 里 的 内 容 。 订 阅 组 可 以 被 自动 创建 ， 使 用 
这 个 命令 一 般 是 用 来 修改 订阅 组 ， 指 令 是 updateSubGroup， 表 2-3 列 出 了 
文 持 的 参数 。 








表 2-3 updateSubGroup 


是 否 必 填 说 明 
-b 如 果 -c 为 空 ， 则 必 填 Broker 地 址 ,创建 订阅 组 所 在 的 Broker 


We 
S 





-c 如 果 -b 为 空 ， 则 必 填 Cluster 名 称 ， 创 建 订 阅 组 所 在 的 Cluster 
是 否 容许 广播 方式 消费 
订阅 组 名 


从 哪个 Broker 开始 消费 


' 
TQ 


是 否 容许 从 队列 的 最 小 位 置 开 始 消费 (truelfalse)， 默 认 会 设置 为 


-m A 
true 
消费 失败 的 消息 放 到 一 个 重 试 队 列 ， 每 个 订阅 组 配置 的 重 试 队列 
-q AT eip 上 
@ Ht 
-I if 重 试 消 费 最 大 次 数 ， 超 过 则 投递 到 死 信 队 列 


消费 功能 是 否 开启 


发 现 消 息 堆 积 后 ， 将 Consumer 的 消费 请 求 重 定向 到 另外 一 台 
Broker 机 器 


打印 帮助 


NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2: 
9876... 


1 
= 
Shee 一 N =N 


4. 删 除 订 阅 组 


与 创建 或 修改 订阅 组 相对 应 ， 这 个 命令 删除 不 再 使 用 的 订阅 组 ， 指 
令 是 deleteSubGroup， 表 2-4 列 出 了 文 持 的 参数 。 


表 2-4 deleteSubGroup 


说 明 
如果 -c 为 空 ， 则 必 填 | Broker 地 址 ， 删 除 订 阅 组 所 在 的 Broker 





如 果 -b HZ, MPY | Cluster 名 称 ， 删 除 订 阅 组 所 在 的 Cluster 


合 打印 帮助 


NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876... 


5. 更 新 Broker 配 置 
Broker 有 很 多 的 配置 信息 ， 在 Broker 启 动 时 ， 可 以 通过 配置 文件 来 


指定 配置 信息 。 有 些 配 置信 息 文 持 在 Broker 运 行 的 时 候 动态 更 改 ， 更 改 
指令 是 updateBrokerConfig， 表 2-5 列 出 了 支持 的 参数 。 


表 2-5 updateBrokerConfig 





说 明 
如 果 -c 为 空 ， 则 必 填 | Broker 名 称 
如 果 -b 为 空 ， 则 必 填 | Cluster 名称， 该 Broker 所 在 的 Cluster 
-n ie NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876... 


6. 更 新 Topic 的 读 写 权限 


RocketMQ 支 持 对 Topic 进 行 权 限 控 制 ， 主 要 分 为 只 读 的 Topic 和 可 读 
写 的 Topic， 权 限 可 以 通过 指令 updateTopicPerm 来 动态 改变 ， 表 2-6 列 出 
了 文 持 的 参数 。 





表 2-6 updateTopicPerm 








-b 如 果 -c 为 空 ， 则 必 填 | Broker 地 址 ，Topic 所 在 的 Broker 
-C 如 果 -b 为 空 ， 则 必 填 | Cluster 名 称 ， 表 示 Topic 所 在 的 集群 
-n NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876 
-p 指定 新 Topic 的 权限 限制 ，(2|4|6), [2:W 4:R; 6:RW] 
7. 查 询 Topic 的 路 由 信息 





Topic 的 路 由 信息 指 的 FeV Topic 在 的 Broker 相 关 信 息 ， 客 户 端 
可 以 通过 NameServer 来 获取 这 些 信 息 ， 本 命令 一 般 在 调试 的 时 候 使 用 ， 
指令 是 TopicRoute， 表 2-7 列 出 了 文 持 的 参数 。 


表 2-7 TopicRoute 


参数 是 否 必 填 说 明 


m 打印 帮助 
NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876 


Topic 名 称 


8. 查 看 Topic 列 表 信 息 


上 面 提 到 的 TopicRoute 是 列 出 某 个 Topic 的 相关 信息 ， 还 有 个 指令 
TopicList 用 来 列 出 集群 中 所 有 Topic 的 名 称 ， 表 2-8 列 出 了 支持 的 参数 。 


表 2-8 TopicList 


it AA 


yu. 





9. 查 看 Topic 统 计 信 息 


在 使 用 RocketMQ 的 时 候 ， 经 常 需要 查看 人 条 个 Topic 的 状态 ， 看 看 消 
恩 的 数量 ， 有 多 少 未 处 理 等 ， 此 时 可 以 通过 指令 TopicStats 来 得 询 ， 表 2- 
9 列 出 了 支持 的 参数 。 








表 2-9 TopicStats 


Bu or 

-t Topic 名 称 

-h f 打印 帮助 

-n NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876... 





10. 根 据 时 间 查 询 消 筷 


一 条 消息 被 发 送 到 RocketMQ 后 ， 默 认 会 带 上 发 送 的 时 间 戳 ， 所 以 
我 们 可 以 根据 估计 的 时 间 来 查询 消息 ， 指 令 是 printMsg， 表 2-10 列 出 了 
支持 的 参数 。 





表 2-10 printMsg 


参数 | 是 否 必 填 说 明 


-b A FREER, at: currentTimeMillis|lyyyy-MM-dd#HH:mm:ss:SSS 
-d AF SRA AK, Ahab: currentTimeMillis|yyyy-MM-dd#HH:mm:ss:SS$ 
-h 打印 帮助 


Tag 名 称 举例 : TagA || TagB 
NameServe 服务 地 考 列 表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876... 


| 








11. 根 据 消 息 ID 查询 消息 


根据 消息 ID 可 以 精确 定位 到 某 条 消息 ， 但 是 消息 ID 需要 通过 其 他 方 
式 来 获取 ， 比 如 可 以 先 用 时 间 来 查询 出 一 些 消息 ， 然 后 定位 到 要 找 的 具 
体 某 个 消息 ， 指 令 是 queryMsgById， 表 2-11 列 出 了 支持 的 参数 。 











表 2-11 queryMsgByld 


参数 是 否 必 填 说 明 
-i fi: 消息 ID 
-h 打印 帮助 


-n NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876;192.168.0.2:9876... 


12. 查 看 集群 消 筷 


指令 clusterList 用 来 列 出 集群 的 状态 ， 看 看 有 哪些 Broker 在 提供 服 
务 ， 表 2-12 列 出 了 支持 的 参数 。 


表 2-12 clusterList 


参数 说 明 
-m 是 否 打印 更 多 信息 
( 续 ) 
参数 说 明 
-h 打印 帮助 


NameServe 服务 地 址 列表 ， 举 例 : 192.168.0.1:9876:192.168.0.2:9876... 





2.55 通过 图 形 界 面 管 理 集群 


对 于 RocketMQ 新 手 ， 可 以 局 动 运 维 服务 ， 从 页 面 上 直观 看 到 消息 
队列 集群 的 状态 。 有 一 定 经 验 以 后 ， 可 以 使 用 命令 行 更 快捷 ， 其 功能 更 


o 


运 维 服务 程序 是 个 SpringBoot 项 目 ， 需 要 从 GitHub 上 的 
apache/rocketmq-externals 里 下 载 源码 
Chttps://github.com/apache/rocketmq-externals/tree/master/rocketmq- 
console ) 。 


进入 下 载 源 码 的 目录 ， 运 行 如 下 命令 即 可 局 动 : 





mvn spring-boot:run 





也 可 以 编译 成 jar 包 ， 通 过 java-jar 来 执行 。 


服务 启动 后 ， 在 浏览 器 里 访问 server_ip_address: 
8080 〈server ip_address 是 启动 rocketmq-console 的 机 器 IP) 地 址 就 可 看 
到 集群 的 状态 。 


RocketMq-Console-Ng OPS Dashboard Cluster Topic Consumer Producer Message 


Date: 


Broker TOP 10 EB TotalMsg Broker 5min trend 

-二 broker 
5000.00 - 1.005 
4000.00 0.804 


3000.00 0.604 






2000.00 + 0.404 


1000.00 0.204 





0.00 0.00. 
broker—47:0 broker—108:0 broker—47:1 06:53:00 06:59:00 07:05:00 


图 2-2 rocketmq-console J [i] 


2.6 本章 小 结 


在 生产 环境 中 使 用 RocketMQ 集 群 需要 比 QuickStart 部 分 了 解 更 多 的 
内 容 ， 本 章 在 机 器 角色 、 集 群 配 置 和 部 署 ， 以 及 集群 管理 方面 都 做 了 介 
绍 ， 用 户 可 以 基于 这 些 内 容 搭建 起 一 个 生成 环境 的 RocketMQ 消 息 队列 
集群 ， 在 数据 量 不 大 的 非 关键 场景 ， 可 以 通过 这 一 章 快速 上 线 。 下 一 章 
重点 讲 如 何 用 好 RocketMQ， 即 根据 实际 场景 选择 合适 的 发 送 消息 和 接 
收 消息 的 方式 。 











第 3 革 HES DAKSA E 


生产 者 和 消费 者 是 消息 队列 的 两 个 重要 角色 ， 生 产 者 向 消息 队列 写 
入 数据 ， 消 费 者 从 消息 队列 里 读 取 数 据 ，RocketMQ 的 大 部 分 用 户 只 需 
要 和 生产 者 、 消 费 者 打交道 。 本 章 具 体 介绍 不 同类 型 生产 者 和 消费 者 的 
特点 ， 以 及 和 它们 相关 的 Offset 和 Log。 





3.1 不 同 闪 型 的 消费 者 


根据 使 用 者 对 读 取 操作 的 控制 情况 ， 消 费 者 可 分 为 两 种 类 型 。 一 个 
是 DefaultMQPushConsumer， 由 系统 控制 读 取 操 作 ， 收 到 消息 后 自动 调 
用 传 入 的 处 理 方法 来 处 理 ， 另 一 个 是 DefaultMQPullConsumer， 读 取 操 
作 中 的 大 部 分 功能 由 使 用 者 自主 控制 。 


3.1.1 _ DefaultMQPushConsumer 的 使 用 


使 用 DefaultMQPushConsumer 主 要 是 设置 好 各 种 参数 和 传 入 处 理 消 
恩 的 函数 。 系 统 收 到 消息 后 自动 调用 处 理 函 数 来 处 理 消 息 ， 上 自动 保存 
Offset， 而 且 加 入 新 的 DefaultMQPushConsumer 后 会 目 动 做 负载 均衡 。 下 
面 结合 org.apache.rocketmq.example.quickstart 包 中 的 源码 来 介绍 ， 如 代 
码 清 单 3-1 所 示 。 


代码 清单 3-1 DefaultMQPushConsumer 示 例 








public class QuickStart { 
public static void main(String[] args) throws InterruptedException, MQClientExce 
DefaultMQPushConsumer Consumer = new DefaultMQPushConsumer ("please_rename_t 
Consumer .setNamesrvAddr ("name-serveri-ip:9876;name-server2-ip:9876"); 
Consumer . setConsumeFromwhere(ConsumeFromwhere.CONSUME_FROM_FIRST_OFFSET); 
Consumer .setMessageModel(MessageModel.BROADCASTING) ; 


Consumer.subscribe("TopicTest", "*"); 
Consumer .registerMessageListener(new MessageListenerConcurrently() { 
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, 
System.out.printf(Thread.currentThread().getName() + " Receive New 下 
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; 


3); 
Consumer.start(); 
} 
} 





DefaultMQPushConsumer 需 要 设置 三 个 参数 : 一 是 这 个 Consumer 的 
GroupName， 二 是 NameServer 的 地 址 和 端口 号 ， 三 是 Topic 的 名 称 ， 下 
面 将 分 别 进 行 详细 介绍 。 


1) Consumer 的 GroupName 用 于 把 多 个 Consumer 组 织 到 一 起 ， 提 高 
并 发 处 理 能 力 ，GroupName 需 要 和 消息 模式 〈MessageModel) 配合 使 
用 。 


RocketMQ 文 持 两 种 消息 模式 : Clustering 和 Broadcasting。 


.在 Clustering 模 式 下 ， 同 一 个 ConsumerGroup (GroupName 相 同 ) 里 
的 每 个 Consumer 只 消费 所 订阅 消息 的 一 部 分 内 容 ， 同 一 个 
ConsumerGroup 里 所 有 的 Consumer 消 费 的 内 容 合 起 来 才 是 所 订阅 Topic 内 
容 的 整体 ， 从 而 达到 负载 均衡 的 目的 。 


.在 Broadcasting 模 式 下 ， 同 一 个 ConsumerGroup 里 的 每 个 Consumer 
都 能 消费 到 所 订阅 Topic 的 全 部 消息 ， 也 惑 是 一 个 消 上 息 会 被 多 次 分 发 ， 
被 多 个 Consumer 消 费 。 


2) NameServer 的 地 址 和 端口 号 ， 可 以 填写 多 个 ， 用 分 号 隔 开 ， 达 
到 消除 单 点 故障 的 目的 ， 比 如 “ip1: port; ip2: port; ip3: port”. 


3) Topic 名 称 用 来 标识 消 恩 类 型 ， 需 要 提前 创建 。 如 果 不 需要 消费 
某 个 Topic 下 的 所 有 消息， 可 以 通过 指定 消 四 的 Tag 进 行 消 息 过 滤 ， 毕 
如 : Consumer.subscribe ("TopicTest", "tag1||tag2||tag3") ， 表 示 这 个 
Consumer 要 消费 “TopicTest” 下 带 有 tag1 或 tag2 或 tag3 的 消息 〈Tag 是 在 发 
送 消息 时 设置 的 标签 ) 。 在 填写 Tag 参 数 的 位 置 ， 用 null 或 者 “*” 表 示 要 
消费 这 个 Topic 的 所 有 消息 。 











3.1.2 DefaultMQPushConsumer 的 处 理 流程 


本 节 通 过 分 析 源 人 码 来 说 明 DefaultMQPushConsumer 的 处 理 流 程 。 


DefaultMQPushConsumer 主 要 功能 实现 在 
DefaultMQPushConsumerImpl 类 中 ， 消 息 的 处 理 逻 辑 是 在 pullMessage 这 
个 函数 里 的 PullCallBack 中 。 在 PullCallBack 函 数 里 有 个 switch 语 句 ， 根 
据 从 Broker 返 回 的 消息 类 型 做 相应 的 处 理 ， 具 体 处 理 逻 辑 可 以 查看 源 
码 ， 如 代码 清单 3-2 所 示 。 


代码 清单 3-2 DefaultMQPushConsuer 的 处 理 逻 辑 





switch (pullResult.getPullStatus()) { 
case FOUND: 





DefaultMQPushConsuer 的 源码 中 有 很 多 PullRequest 语 句 ， 比 如 
Default- 
MQPushConsumerImpl.this.executePullRequestImmediately (pullRequest) 
为 什么 “PushConsumer” 中 使 用 “PullRequest” 呢 ?这 是 通过 “长 轮 询 ”方式 
oo 的 方法 ， 长 轮 询 方式 既 有 Pull 的 优点 ， 又 兼 具 Push 方 式 的 
实时 性 。 


Push 方 式 是 Server 端 接收 到 消息 后 ， 主 动 把 消息 推送 给 Client 疹 ， 实 
时 性 高 。 对 于 一 个 提供 队列 服务 的 Server 来 说 ， 用 Push 方 式 主动 推送 有 
(RS Weg: 首先 是 加 大 Server 端 的 工作 量 ， 进 而 影响 Server 的 性 能 ， 其 
次 ，Client 的 处 理 能 力 各 不 相同 ，Client 的 状态 不 受 Server 控 制 ， 如 果 
Client 不 能 及 时 处 理 Server 推 送 过 来 的 消息 ， 会 造成 各 种 潜在 问题 。 


Pul] 方 式 是 Client 端 循环 地 从 Server 端 拉 取 消息 ， 主 动 权 在 Client 手 











里 ， 自 己 拉 取 到 一 定量 消息 后 ， 处 理 妥 当 了 再 接着 取 。Pul] 方 式 的 问题 
是 循环 拉 取 消息 的 间隔 不 好 设 定 ， 间 隔 太 短 就 处 在 一 个 “ 忙 等 >” 的 状态 ， 
浪费 资源 ， 每 个 Pull 的 时 间 间 隔 太 长 ，Server 问 有 消息 到 来 时 ， 有 可 能 
没有 被 及 时 处 理 。 

“长 轮 询 * 方 式 通 过 Client 端 和 Server 端 的 配合 ， 达 到 既 拥 有 Pull 的 优 
人 ee 我 们 结合 源码 来 分 析 ， 如 代码 清单 3- 
3 和 3-4 所 示 。 


代码 清单 3-3 ”发 送 Pull 消 息 代 码 片段 





PullMessageRequestHeader requestHeader = new PullMessageRequestHeader(); 
requestHeader .setConsumerGroup(this.ConsumerGroup) ; 
requestHeader.setTopic(mq.getTopic()); 

requestHeader .setQueueId(mq.getQueueld()); 

requestHeader .setQueueOffset (Offset); 

requestHeader .setMaxMsgNums(maxNums ) ; 
requestHeader.setSysFlag(sysFlagInner) ; 
requestHeader.setCommitOffset(commitOffset ); 

requestHeader ..setSuspendTimeoutMillis(brokerSuspendMaxTimeMillis) ; 
requestHeader.setSubscription(subExpression); 
requestHeader.setSubVersion(subVersion) ; 
requestHeader.setExpressionType(expressionType) ; 


PullResult pullResult = this.mQClientFactory.getMQClientAPIImp1().pullMessage( 
brokerAddr, requestHeader, timeoutMillis, communicationMode, pullCallback); 





源码 中 有 这 一 行 设 置 语句 
requestHeader.setSuspendTimeoutMillis (brokerSus- 
pendMaxTimeMillis) ， 作 用 是 设置 Broker 最 长 阻塞 时 间 ， 默 认 设 置 是 15 
秒 ， 注 意 是 Broker 在 没有 新 消息 的 时 候 才 阻塞 ， 有 消息 会 立刻 返回 。 


代码 清单 3-4 “长 轮 询 ” 服 务 端 代码 片段 





package org.apache.rocketmq.broker.longpolling 

if (this.brokerController.getBrokerConfig().isLongPollingEnable()) { 
this.waitForRunning(5 * 1000); 

} else { 
this.waitForRunning(this.brokerController.getBrokerConfig().getShortPollingTimel 


long beginLockTimestamp = this.systemClock.now(); 
this.checkHoldRequest(); 
long costTime = this.systemClock.now() - beginLockTimestamp; 
if (costTime > 5 * 1000) { 
Log.info("[NOTIFYME] check hold request cost {} ms.", costTime) ; 


eee | 


从 Broker 的 源码 中 可 以 看 出 ， 服 务 端 接 到 新 消息 请 求 后 ， 如 果 队 列 
里 没有 新 消息 ， 并 不 急于 返回 ， 通 过 一 个 循环 不 断 查 看 状态 ， 每 次 
waitForRunning 一 段 时 间 (默认 是 5 秒 〉， 然 后 后 再 Check。 默 认 情 况 下 
当 Broker 一 直 没 有 新 消息 ， 第 三 次 Check 的 时 候 ， 等 待 时 间 超 过 Request 
里 面 的 Broker-SuspendMaxTimeMillis， 就 返回 空 结 果 。 在 等 待 的 过 程 
中 ，Broker 收 到 了 新 的 消息 后 会 直接 调用 notifyMessageArriving 函 数 返 回 
请 求 结 果 。“ 长 轮 询 ”的 核心 是 ，Broker 端 HOLD 住 客户 端 过 来 的 请 求 一 
小 段 时 间 ， 在 这 个 时 间 内 有 新 消息 到 达 ， 就 利用 现 有 的 连接 立刻 返回 消 
四 给 Consumer。 “长 轮 询 ” 的 主动 权 还 是 掌握 在 Consumer 手 中 ，Broker 即 
使 有 大 量 消 息 积 压 ， 也 不 会 主动 推送 给 Consumer。 


长 轮 询 方式 的 局 限 性 ， 是 在 HOLD 住 Consumer 请 求 的 时 候 需 要 占用 
资源 ， 它 适合 用 在 消息 队列 这 种 客户 端 连 接 数 可 控 的 场景 中 。 























3.1.3 DefaultMQPushConsumer 的 流量 控制 


本 节 分 析 PushConsumer 的 流量 控制 方法 。PushConsumer 的 核心 还 是 
Pul] 方 式 ， 所 以 采用 这 种 方式 的 客户 端 能 够 根据 自身 的 处 理 速度 调整 获 
取消 恩 的 操作 速度 。 因 为 采用 多 线程 处 理 方式 实现 ， 流 量 控 制 的 方面 比 
单线 程 要 复杂 得 多 。 


PushConsumer 有 个 线程 池 ， 消 息 处 理 逻 辑 在 各 个 线程 里 同时 执行 ， 
这 个 线程 池 的 定义 如 代码 清单 3-5 所 示 。 


代码 清单 3-5 ”DefaultMQPushConsumer 的 线程 池 定 义 





this.consumeExecutor = new ThreadPoolExecutor ( 
this .defaultMQPushConsumer .getConsumeThreadMin( ), 
this .defaultMQPushConsumer .getConsumeThreadMax(), 
1000 * 60, 
TimeUnit .MILLISECONDS, 
this .consumeRequestQueue, 
new ThreadFactoryImpl("ConsumeMessageThread_")); 





Pull 获 得 的 消息 ， 如 果 直 接 提 交 到 线程 池 里 执行 ， 很 难 监控 和 控 
制 ， 比 如 ， 如 何 得 知 当前 消息 堆积 的 数量 ?如何 重复 处 理 某 些 消息 ? 如 
何 延迟 处 理 某 些 消息 ? RocketMQ 定 义 了 一 个 快照 类 ProcessQueue 来 解决 
这 些 问题 ， 在 PushConsumer 运 行 的 时 候 ， 每 个 Message Queue 都 会 有 个 
对 应 的 ProcessQueue 对 象 ， 保 存 了 这 个 Message Queue 消 息 处 理 状 态 的 快 


WEI 
Ha 


ProcessQueue 对 象 里 主要 的 内 容 是 一 个 TreeMap 和 一 个 读 写 锁 。 
TreeMap 里 以 Message Queue 的 Offset 作 为 Key， 以 消息 内 容 的 引用 为 
Value, {ett S PTA \MessageQueuesr AX FI, (AER AR BEARER ATE AS 
读 写 锁 控 制 着 多 个 线程 对 TreeMap 对 象 的 并 发 访问 。 


有 了 ProcessQueue 对 象 ， 流 量 控制 就 方便 和 灵活 多 了 ， 客 户 并 在 每 
次 Pull 请 求 前 会 做 下 面 三 个 判断 来 控制 流量 ， 如 代码 清单 3-6 所 示 。 


代码 清单 3-6 ”PushConsumer 的 流量 控制 逻辑 





long cachedMessageCount = processQueue.getMsgCount().get(); 


long cachedMessageSizeInMiB = processQueue.getMsgSize().get() / (1024 * 1024); 


if (cachedMessageCount > this.defaultMQPushConsumer .getPullThresholdForQueue()) { 
this.executePullRequestLater(pullRequest, PULL_TIME_DELAY_MILLS_WHEN_FLOW_CONTRC 
if ((queueFlowControlTimes++ % 1000) == 0) { 
log.warn( 
"the cached message count exceeds the threshold {}, so do flow control, 
this .defaultMQPushConsumer .getPullThresholdForQueue(), processQueue.geth 





} 


return; 


if (cachedMessageSizeInMiB > this.defaultMQPushConsumer .getPullThresholdSize-ForQuet 
this.executePullRequestLater(pullRequest, PULL_TIME_DELAY_MILLS_WHEN_FLOW_CONTRC 
if ((queueFlowControlTimes++ % 1000) == 0) { 
log.warn( 
"the cached message size exceeds the threshold {} MiB, so do flow contrc 
this .defaultMQPushConsumer .getPullThresholdSizeForQueue(), processQueue. 





} 


return; 


if (!this.consumeOrderly) { 

if (processQueue.getMaxSpan() > this.defaultMQPushConsumer .getConsumeConcurrent] 
this.executePullRequestLater(pullRequest, PULL_TIME_DELAY_MILLS_WHEN_FLOW_CC 

if ((queueMaxSpanFlowControlTimest++ % 1000) == 0) { 

log.warn( 

"the queue's messages, span too long, so do flow control, minOffset: 
processQueue.getMsgTreeMap().firstKey(), processQueue.getMsgTreeMap ( 

pullRequest, queueMaxSpanFlowControlTimes) ; 





} 


return; 





从 代码 中 可 以 看 出 ，PushConsumer 会 判断 获取 但 还 未 处 理 的 消息 个 
数 、 消 息 总 大 小 、Offset 的 跨度 ， 任 何 一 个 值 超过 设 定 的 大 小 束 隔 一 段 
时 间 再 拉 取 消息 ， 从 而 达到 流量 控制 的 目的 。 此 外 ProcessQueue 还 可 以 
辅助 实现 顺序 消费 的 逻辑 。 


3.1.4 DefaultMQPullConsumer 


使 用 DefaultMQPullConsumer 像 使 用 DefaultMQPushConsumer 一 样 需 
要 设置 各 种 参数 ， 写 处 理 消 息 的 函数 ， 同 时 还 需要 做 额外 的 事 : i 。 接 下 
来 结合 org.apache.rocketmq.example.simple 包 中 的 例子 源码 来 介绍 ， 如 代 
码 清单 3-7 所 示 。 


代码 清单 3-7” PullConsumer 示 例 





public class PullConsumer { 
private static final Map<MessageQueue, Long> OFFSE_TABLE = new HashMap<MessageQt 


public static void main(String[] args) throws MQClientException { 
DefaultMQPullConsumer Consumer = new DefaultMQPullConsumer ("please_rename_t 
Consumer.start(); 
Set<MessageQueue> mqs = Consumer .fetchSubscribeMessageQueues("TopicTesti"); 
for (MessageQueue mq : mqs) { 
long Offset = Consumer.fetchConsumeOffset(mq, true); 
System.out.printf("Consume from the Queue: " + mq + "%n"); 
SINGLE_MQ: 
while (true) { 
try { 
PullResult pullResult = 
Consumer .pullBlockIfNotFound(mq, null, getMessage-QueueOfFfse 
System.out.printf("%s%n", pullResult); 
putMessageQueueOffset(mg, pullResult.getNextBegin-Offset()); 
switch (pullResult.getPullStatus()) { 
case FOUND: 
break; 
case NO_MATCHED_MSG: 
break; 
case NO_NEW_MSG: 
break SINGLE_MQ; 
case OFFSET_ILLEGAL: 
break; 
default: 
break; 


} 
} catch (Exception e) { 
e.printStackTrace(); 
} 


} 


Consumer. shutdown(); 


private static long getMessageQueueOffset(MessageQueue mq) { 
Long Offset = OFFSE_TABLE.get(mq); 
if (Offset != null) 
return Offset; 
return 0; 


private static void putMessageQueueOffset(MessageQueue mq, long Offset) { 
OFFSE_TABLE.put(mg, Offset); 
} 


Ce ee ee ee 
， 读 完 一 遍 后 退出 ， 主 要 处 理 额 外 的 三 件 事情 : 


(1) 获取 Message Queue 并 遍历 


oy 


=| Topical if | Message Queue， 如 果 这 个 Consumer 需 要 获取 
Topic FAT AME, MEW ZA Message Queue。 如 果 有 特殊 情 
况 ， 也 可 以 选择 某 些 特定 的 Message Queue 来 读 取消 息 。 


(2) 维护 Offsetstore 


从 一 个 Message Queue 里 拉 取 消息 的 时 候 ， 要 传 入 Offset 参 数 Adong 
类 型 的 值 ) ， 随 着 不 断 读 取消 息 ，Offset 会 不 断 增长 。 这 个 时 候 由 用 户 
根据 具体 情况 可 以 存 到 内 存 里 、 写 到 磁盘 或 者 
数据 库 里 等 。 


(3) 根据 不 同 的 消 奶 状态 做 不 同 的 处 理 


拉 取 消息 的 请 求 发 出 后 ， 会 返回 : FOUND、 
NO_MATCHED_ MSG、NO_NEW_MSG、OFFSET ILLEGAL 四 种 状 
态 ， 需 要 根据 每 个 状态 做 不 同 的 处 理 。 比 较 重 要 的 两 个 状态 是 FOUNT 
和 NO_NEW_MSG， 分 别 表 示 获 取 到 消息 和 没有 新 的 消息 。 


实际 情况 中 可 以 把 while (true) 放 到 外 层 ， 达 到 无 限 循环 的 目的 。 
因为 PullConsumer 需 要 用 户 自己 处 理 裔 历 Message Queue、 保 存 Offset， 
所 以 PullConsumer 有 更 多 的 自主 性 和 灵活 性 。 





3.1.5 Consumer JAS. KAYE 


消息 队列 一 般 是 提供 一 个 不 间断 的 持续 性 服务 ，Consumer 在 使 用 过 
程 中 ， 如 何 才 能 优雅 地 局 动 和 关闭 ， 硝 保 不 漏 掉 或 者 重复 消费 消息 呢 ? 


Consumer 分 为 Push 和 Pull 两 种 方式 ， 对 于 PullConsumer 来 说 ， 使 用 
者 主动 权 很 高 ， 可 以 根据 实际 需要 和 暂停、 停止 、 启 动 消费 过 程 。 需 要 注 
意 的 是 Offset 的 保存 ， 要 在 程序 的 异 稼 处 理 部 分 增加 把 Offset 写 入 磁盘 方 
面 的 处 理 ， 记 准 了 每 个 Message Queue 的 Offset， 才 能 保证 消息 消费 的 准 
确 性 。 


DefaultMQPushConsumer 的 退出 ， 要 调用 shutdown () 函数 ， 以 便 
释放 资源 、 保 存 Offset 等 。 这 个 调用 要 加 到 Consumer 所 在 应 用 的 退出 多 
辑 中 。 


PushConsumer 在 启动 的 时 候 ， 会 做 各 种 配置 检查 ， 然 后 连接 
NameServer 获 取 Topic 信 息 ， 启 动 时 如 果 壳 到 异常 ， 比 如 无 法 连接 
NameServer， 程 序 仍然 可 以 正常 启动 不 报错 (日志 里 有 WARN 人 信息) o 
在 单机 环境 下 可 以 测试 这 种 情况 ， 启 动 DefaultMQPushConsumer 时 故意 
把 NameServer 地 址 填 错 ， 程 序 仍然 可 以 正常 局 动 ， 但 是 不 会 收 到 消息 。 


为 什么 DefaultMQPushConsumer 在 无 法 连接 NameServer 时 不 直接 报 
错 退 出 呢 ? 这 和 分 布 式 系统 的 设计 有 关 ，RocketMQ 集 群 可 以 有 多 个 
NameServer、Broker， 某 个 机 器 出 异常 后 整体 服务 依然 可 用 。 所 以 
DefaultMQPushConsumer 被 设计 成 当 发 现 某 个 连接 异常 时 不 立刻 退出 ， 
而 是 不 断 党 试 重 新 连接 。 可 以 进行 这 样 一 个 测试 ， 在 
DefaultMQPushConsumer 正 和 常 运 行 的 时 候 ， 手 动 kill 挤 Broker 或 
NameServer， 过 一 会 儿 再 启动 。 会 发 现 DefaultMQPushConsumer 不 会 出 
错 退 出 ， 在 服务 恢复 后 正常 运行 ， 在 服务 不 可 用 的 这 段 时 间 ， 仪 仅 会 在 
日 志 里 报 异常 信息 。 


如 果 需 要 在 DefaultMQPushConsumer 启 动 的 时 候 ， 及 时 暴露 配置 问 
题 ， 访 如何 操作 呢 ? 可 以 在 Consumer.start O 语句 后 调用 : 
Consumer.fetchSubscribeMe-ssageQueues ("TopicName") ， 这 时 如 果 配 
置信 息 写 得 不 准确 ， 或 者 当前 服务 不 可 用 ， 这 个 语句 会 报 
MQClientException 异 节 。 
































3.2 不 同类 型 的 生产 者 


生产 者 回 消 妃 队 列 里 写 入 消息 ， 不 同 的 业务 场景 需要 生产 者 采用 不 
同 的 写 入 集 略 。 比 如 同步 及 送 、 寞 步 友 送 、 延 迟 发 送 、 帮 送 事务 消 忆 
等 ， 下 面具 体 介 绍 。 





3.2.1 DefaultMQProducer 





生产 者 发 送 消息 默认 使 用 的 是 DefaultMQProducer 类 ， 下 面 结合 实 
际 代 码 来 详细 解释 ， 如 代码 清单 3-8 所 示 。 


代码 清单 3-8 ”DefaultMQProduce 示 例 





public class ProducerQuickStart { 
public static void main(String[] args) throws MQClientException, InterruptedExce 
DefaultMQProducer producer = new DefaultMQProducer ("please_rename_unique_group_r 
producer.setInstanceName("instance1") ; 
producer.setRetryTimeswhenSendFailed(3); 
producer .setNamesrvAddr ("name-server1-ip:9876;name-server2-ip:9876"); 
Producer.start(); 
for (int i = 0; i < 1000; i++) { 
try { 
Message msg = new Message("TopicTest" /* Topic */, 
"TagA" /* Tag * 
("Hello RocketMQ_ " + 1).getBytes(RemotingHelper .DEFAULT_CHARSET)} 





了 
Producer.send(msg, new SendCallback() 
public void onSuccess(SendResult sendResult) { 
System.out.printf("%s%n", sendResult); 
sendResult.getSendStatus(); 


public void onException(Throwable e) { 
e.printStackTrace(); 


J); 

} catch (Exception e) { 
e.printStackTrace(); 
Thread.sleep(1000); 


producer.shutdown(); 





发 送 消息 要 经 过 五 个 步骤 : 
1) 设置 Producer 的 GroupName。 
2) 设置 InstanceName， 当 一 个 Jvm 需 要 局 动 多 个 Producer 的 时 候 ， 


通过 设置 不 同 的 InstanceName 来 区 分 ， 不 设置 的 话 系统 使 用 默认 名 
称 “DEFAULT”。 





3) 设置 及 送 失 败 重 试 次 数 ， 当 网 络 出 现 异 常 的 时 候 ， 这 个 次 数 影 
MI SY IS RB. AREA AI, We BLK. 





4) 设置 NameServer 地 址 。 
5) 组 装 消息 并 发 送 。 


消息 的 发 送 有 同步 和 异步 两 种 方式 ， 上 面 的 代码 使 用 的 是 异步 方 
式 。 在 第 2 章 的 例子 中 用 的 是 同步 方式 。 消 息 发 送 的 返回 状态 有 如 下 四 
种 : FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT、 
SLAVE_NOT_AVAILABLE, SEND_OK, 不 同 状 态 在 不 同 的 刷 盘 策略 
和 同步 策略 的 配置 下 含义 是 不 同 的 。 


-FLUSH_DISK_TIMEOUT: 表示 没有 在 规定 时 间 内 完成 刷 盘 〈 需 
要 Broker 的 刷 盘 策略 被 设置 成 SYNC_FLUSH 才 会 报 这 个 错误 ) 。 





-FLUSH_SLAVE_TIMEOUT: 表示 在 主 备 方式 下 ， 并 且 Broker 被 设 
置 成 SYNC_MASTER 方 式 ， 没 有 在 设 定时 间 内 完成 主 从 同步 。 





‘SLAVE. NOT _ AVAILABLE: 这 个 状态 产生 的 场景 和 
FLUSH_SLAVE_TIMEOUT 类 似 ， 表 示 在 主 备 方式 下 ， 并 且 Broker 被 设 
置 成 SYNC_MASTER， 但 是 没有 找到 被 配置 成 Slave 的 Broker。 


‘SEND_OK: 表示 发 送 成 功 ， 发 送 成 功 的 具体 合 义 ， 比 如 消息 是 否 
CARTERA? 消息 是 否 被 同步 到 了 Slave 上 ? 消息 在 Slave 上 是 人 否 
被 写 入 人 磁盘? 需要 结合 所 配置 的 刷 盘 策略 、 主 从 策略 来 定 。 这 个 状态 还 
可 以 简单 理解 为 ， 没 有 发 生 上 面 列 出 的 三 个 问题 状态 就 是 SEND_OK。 


写 一 个 局 质量 的 生产 者 程序 ， 重 点 在 于 对 发 送 结果 的 处 理 ， 要 充分 
考虑 各 种 寞 第 ， 写 清 对 应 的 处 理 逻 辑 。 











3.2.2 RIAGEIRY A 


RocketMQ 支 持 发 送 延 迟 消 息 ，Broker 收 到 这 类 消息 后 ， 延 迟 一 段 
时 间 再 处 理 ， 使 消息 在 规定 的 一 段 时 间 后 生效 。 


延迟 消息 的 使 用 方法 是 在 创建 Message 对 象 时 ， 调 用 
setDelayTimeLevel (int level) 方法 设置 延迟 时 间 ， 然 后 再 把 这 个 消息 发 
送出 去 。 目 前 延迟 的 时 间 不 文 持 任意 设置 ， 仅 文 持 预 设 值 的 时 间 长 度 
(1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h) 。 
比如 setDelayTimeLevel (3) 表示 延迟 10s。 


3.2.3 ASAE ARIS! 


一 个 Topic 会 有 多 个 Message Queue， 如 果 使 用 Producer 的 默认 配 
置 ， 这 个 Producer 会 轮流 向 各 个 Message Queue 发 送 消息 。Consumer 在 消 
忱 消息 的 时 候 ， 会 根据 负载 均衡 策略 ， 消 费 被 分 配 到 的 Message 
Queue， 如 果 不 经 过 特定 的 设置 ， 某 条 消息 被 发 往 哪 个 Message Queue, 
被 哪个 Consumer 消 费 是 未 知 的 。 

如 果 业 务 需要 我 们 把 消息 发 送 到 指定 的 Message Queue 里 ， 比 如 把 
同一 类 型 的 消息 都 发 往 相 同 的 Message Queue， 该 怎么 办 呢 ? 可 以 用 
Message-QueueSelector， 如 代码 清单 3-9 所 示 。 


代码 清单 3-9 ”MessageQueueSelector 示 例 





public class OrderMessageQueueSelector implements MessageQueueSelector { 
public MessageQueue select(List<MessageQueue> mqs, Message msg, 
int id = Integer.parseInt(orderKey.toString()); 
int idMainIndex = id/100; 
int size = mqs.size(); 
int index = idMainIndex%size; 
return mqs.get(index) ; 





发 送 消息 的 时 候 ， 把 MessageQueueSelector 的 对 象 作为 参数 ， 使 用 
public SendResult send (Message msg, MessageQueueSelector selector, 
Object arg) 函数 发 送 消息 即 可 。 在 MessageQueueSelector 的 实现 中 ， 根 
据 传 入 的 Object 人 参数， 或 者 根据 Message 消 息 内 容 确 定 把 消息 发 往 那 个 
Message Queue， 返 回 被 选中 的 Message Queue. 


3.2.4 ”对 事务 的 支持 


RocketMQ 的 事务 消 妃 ， 是 指 发 送 消 息 事 件 和 其 他 事件 需要 同时 成 
功 或 同时 失败 。 比 如 银行 转账 ，A 银 行 的 茶 账 户 要 转 一 万 元 到 B 银 行 的 
某 账 户 。A 银 行 发 送 “银行 账 尸 增加 一 万 元 ”这 个 消 轧 ， 要 和 “从 A 银 行 
账户 扣除 一 万 元 ”这 个 操作 同时 成 功 或 者 同时 失败 。 


RocketMQ 采 用 两 阶段 提交 的 方式 实现 事务 消息 ， 
TransactionMQProducer 处 理 上 面 情况 的 流程 是 ， 先 发 一 个 “准备 从 B 银 行 
账户 增加 一 万 元 ”的 消息 ， 发 送 成 功 后 做 从 A 银 行 账 户 扣 除 一 万 元 的 操 
作 ， 根 据 操作 结果 是 否 成 功 ， 确 定之 前 的 “准备 从 B 银 行 账户 增加 一 万 
元 ”的 消息 是 做 commit 还 是 rollback， 有 具体 流程 如 下 : 


1) 发 送 方 回 RocketMQ 发 送 “ 竺 确认 ”消息 。 


2) RocketMQ 将 收 到 的 “ 待 确认 ”消息 持久 化 成 功 后 ， 同 发 送 方 回 复 
消息 已 经 发 送 成 功 ， 此 时 第 一 阶段 消息 发 送 完成 。 
3) 发 送 方 开始 执行 本 地 事件 逻辑 。 
4) 发 送 方 根据 本 地 事件 执行 结果 癌 RocketMQ 发 送 二 次 确认 
(CCommit 或 是 Rollback) 消息 ，RocketMQ 收 到 Commit 状 态 则 将 第 一 阶 


段 消 息 标 记 为 可 投递 ， 订 阅 方 将 能 够 收 到 该 消 轧 ， 收 到 Rollback 状 态 则 
删除 第 一 阶段 的 消 轧 ， 订 阅 方 接收 不 到 该 消息 。 


5) 如 果 出 现 异 常情 况 ， 步 又 4) 提交 的 二 次 确认 最 终 未 到 达 
RocketMQ， 服 务 器 在 经 过 固定 时 间 段 后 将 对 “ 符 确 认 ” 消 息 发 起 回答 请 


























6) 发 送 方 收 到 消息 回 查 请 求 后 〈 如 果 发 送 一 阶段 消息 的 Producer 不 
能 工作 ， 回 查 请 求 将 被 发 送 到 和 Producer 在 同一 个 Group 里 的 其 他 
Producer) ， 通 过 检查 对 应 消息 的 本 地 事件 执行 结果 返回 Commit 或 
Roolback 状 态 。 


7) RocketMQ 收 到 回 查 请 求 后 ， 按 照 步 骤 4) 的 逻辑 处 理 。 


上 面 的 逻辑 似乎 很 好 地 实现 了 事务 消息 功能 ， 它 也 是 RocketMQ 之 
前 的 版 本 实现 事务 消息 的 逻辑 。 但 是 因为 RocketMQ 依 赖 将 数据 顺序 写 
到 磁盘 这 个 特征 来 提高 性 能 ， 步 骤 4) 却 需要 更 改 第 一 阶段 消息 的 状 
态 ， 这 样 会 造成 磁盘 Catch 的 脏 页 过 多 ， 降 低 系 统 的 性 能 。 所 以 
RocketMQ 在 4.x 的 版 本 中 将 这 部 分 功能 去 除 。 系 统 中 的 一 些 上 层 Class 都 
还 在 ， 用 户 可 以 根据 实际 需求 实现 自己 的 事务 功能 。 


客户 端 有 三 个 类 来 支持 用 户 实 现 事 务 消 息 ， 第 一 个 类 是 
LocalTransaction-Executer， 用 来 实例 化 步骤 3) 的 逻辑 ， 根 据 情况 返回 
LocalTransactionState. ROLLBACK_MESSAGES 4% 
LocalTransactionState.COMMIT _ MESSAGE 状态 。 第 二 个 类 是 
TransactionMQProducer， 它 的 用 法 和 DefaultMQProducer 类 似 ， 要 通过 它 
启动 一 个 Producer 并 发 消息 ， 但 是 比 DefaultMQProducer 多 设置 本 地 事务 
处 理 函 数 和 回 查 状态 函数 。 第 三 个 类 是 TransactionCheckListener， 实 现 
ERS) 中 MQ 服务 器 的 回 查 请 求 ， 返 回 
LocalTransactionState.ROLLBACK_MESSAGE 或 者 
LocalTransactionState. COMMIT MESSAGE. 














3.3 ”如 何 存储 队列 位 置信 息 


实际 运行 中 的 系统 ， 难免 会 遇 到 重新 消费 某 条 消息 、 跳 过 一 段 时 间 
内 的 消息 等 情况 。 这 些 异 稼 情况 的 处 理 ， 都 和 Oftset 有 关 。 本 节 主 要 分 
析 Offset 的 存储 位 置 ， 以 及 如 何 根据 需要 调整 Offset 的 值 。 


首先 来 明确 一 下 Offset 的 含义 ，RocketMQ 中 ， 一 种 类 型 的 消息 会 放 
到 一 个 Topic 里 ， 为 了 能 够 并 行 ， Be Topica i 3 Message 
Queue 〈 也 可 以 设置 成 一 个 ) ， Offset 是 指示 个 Topic 下 的 条 消息 在 某 
个 Message Queue 里 的 位 置 ， 通过 Offset 的 值 可 以 定位 到 这 SRI, Bee 
指示 Consumer 从 这 条 消息 开始 同 后 继续 处 理 。 


如 图 3-1 所 示 是 Offset 的 类 结构 ， 主 要 分 为 本 地 文件 类 型 和 Broker 代 
存 的 类 型 两 种 。 对 于 DefaultMQPushConsumer 来 说 ， 默 认 是 
CLUSTERING 模 式 ， 也 就 是 同一 个 Consumer group 里 的 多 个 消费 者 每 人 
消费 一 部 分 ， 各 上 自 收 到 的 消息 内 容 不 一 样 。 这 种 情况 下 ， 由 Broker 端 存 
储 和 控制 Offset 的 值 ， 使 用 RemoteBrokerOffsetStore 结 构 。 


OffsetStore 


load 

updateOffset 

readOffset 

persist 
updateConsumeOffsetToBroker 















LocalFileOffsetStore RemoteBrokerOffsetStore 
+readLocalOffset + 
+readLocalOffsetBak fetchConsumeOffsetFromBroker 
图 3-1 OffsetStore 的 类 结构 


在 DefaultMQPushConsumer 里 的 BROADCASTING 模 式 下 ， 每 个 
Consumer 都 收 到 这 个 Topic 的 全 部 消息 ， 各 个 Consumer 间 相互 没有 干 
扰 ，RocketMQ 使 用 LocalFileOffsetStore， 把 Offset 存 到 本 地 。 





OffsetStore 使 用 Json 格 式 存储 ， 简 活 明 了 ， 下 面 是 个 例子 : 
代码 清单 3-10 ”Offsetstore 的 内 容 示 例 





{"OffsetTable":{{"brokerName":"localhost", "QueueId":1,"Topic":"brokeri" }: 1,{ "bre 





在 使 用 DefaultMQPushConsumer 的 时 候 ， 我 们 不 用 关心 OffsetStore 
的 事 ， 但 是 如 果 PullConsumer， 我 们 就 要 自己 处 理 OffsetStore 了。 在 
3.1.4 节 的 PullConsumer 示 例 中 ， 代 码 里 把 Offset 存 到 了 内 存 ， 没 有 持久 
化 存储 ， 这 样 就 可 能 因为 程序 的 异常 或 重启 而 丢失 Offset， 在 实际 应 用 
中 不 推荐 这 样 做 。 接 下 来 给 出 在 磁盘 存储 Offset 的 示例 程序 ， 参 照 
LocalFileOffsetStore 的 源码 编写 ， 如 代码 清单 3-11 所 示 。 


代码 清单 3-11 目 定 义 持久 存储 OffsetStore 











public class LocaloffsetStoreExt { 
private final String groupName; 
private final String storePath; 
private ConcurrentMap<MessageQueue, AtomicLong> OffsetTable = 
new ConcurrentHashMap<MessageQueue, AtomicLong>(); 
public LocalOffsetStoreExt(String storePath, String groupName) { 
this.groupName = groupName; 
this.storePath = storePath; 


} 
public void load() { 
OffsetSerializewrapper OffsetSerializeWrapper = this.readLocal-Offset(); 
if (OffsetSerializeWrapper != null && OffsetSerializewWrapper.getoffsetTablel 
OffsetTable.putAll(OffsetSerializeWrapper.getOffsetTable()); 
for (MessageQueue mq : OffsetSerializeWrapper.getOffsetTable().keySet()° 
AtomicLong Offset = OffsetSerializeWrapper.getOffset-Table().get(mq! 
System.out.printf("load Consumer's Offset, {} {} {} \n", this.group? 


} 


} 
public void updateOffset(MessageQueue mq, long Offset) { 
if (mq != null) { 
AtomicLong OffsetOld = this.OffsetTable.get(mq); 
if (null == OffsetOld) { 
this.OffsetTable.putIfAbsent(mq, new AtomicLong(Offset)); 
} else { 
OffsetOld.set(Offset); 
} 


} 


} 
public long readOffset(final MessageQueue mq) { 
if (mq != null) { 
AtomicLong Offset = this.OffsetTable.get(mq); 
if (Offset != null) { 
return Offset.get(); 
} 


return 0; 


public void persistAll(Set<MessageQueue> mqs) { 
if (null == mqs || mqs.isEmpty()) 
return; 
OffsetSerializeWrapper OffsetSerializeWrapper = new Offset-SerializewWrapper ( 
for (Map.Entry<MessageQueue, AtomicLong> entry : this.OffsetTable. 
entrySet()) { 
if (mqs.contains(entry.getKey())) { 
AtomicLong Offset = entry.getValue(); 
OffsetSerializeWrapper.getOffsetTable().put(entry.getKey(), Offset); 


} 


String jsonString = OffsetSerializewWrapper.toJson(true); 
if (jsonString != null) { 
try { 
MixAll.string2File(jsonString, this.storePath) ; 
} catch (I0Exception e) { 
e.printStackTrace(); 


} 


} 
private OffsetSerializeWrapper readLocaloffset() { 
String content = null; 
try { 
content = MixAll.file2String(this.storePath); 
} catch (IOException e) { 
e.printStackTrace(); 


} 
if (null == content || content.length() == 0) { 
return null; 
} else { 
OffsetSerializeWrapper OffsetSerializeWrapper = null; 
try { 
OffsetSerializeWrapper = 
OffsetSerializeWrapper.fromJson(content, Offset-Serializewré 
} catch (Exception e) { 
e.printStackTrace(); 


return OffsetSerializeWrapper; 





了 解 OffsetStore 的 存储 机 制 以 后 ， 我 们 看 看 如 何 设置 Consumer 读 取 
消息 的 初始 位 置 。DefaultMQPushConsumer 类 里 有 个 函数 用 来 设置 从 哪 
儿 开 始 消 费 消息 : 比如 
setConsumeFromWhere (ConsumeFromWhere.CONSUME_FROM_FIRST._ 
这 个 语句 设置 从 最 小 的 Offset 开 始 读 取 。 如 果 从 队列 开始 到 感 兴趣 的 消 
息 之 间 有 很 大 的 范围 ， 用 CONSUME_FROM _FIRST_OFFSET 人 参数 就 不 
合适 了 ， 可 以 设置 从 某 个 时 间 开 始 消费 消息 ， 比 如 
Consumer.setConsumeF- 
romWhere (ConsumeFromWhere. CONSUME, FROM_TIMESTAMP) , 
Consumer.setConsumeTimestamp ("20131223171201") ， 时 间 惟 格式 是 
精确 到 秒 的 。 


注意 设置 读 取 位 置 不 是 每 次 都 有 效 ， 它 的 优先 级 默认 在 Offset Store 
后 面 ， 比 如 在 DefaultMQPushConsumer 的 BROADCASTING 方 式 下 ， 默 
认 是 从 Broker 里 读 取 某 个 Topic 对 应 ConsumerGroup 的 Offset， 当 读 取 不 
到 Offset 的 时 候 ，ConsumeFromWhere 的 设置 才 生 效 。 大 部 分 情况 下 这 个 
设置 在 Consumer Group 初次 启动 时 有 效 。 如 果 Consumer 正 常 运行 后 被 停 
止 ， 然 后 再 启动 ， 会 接着 上 次 的 Offset 开 始 消费 ，ConsumeFromWhere 的 
设置 无 效 。 


34 目 定 义 日 志 输 出 


Log 是 监控 系统 状态 ， 排 查 问 题 的 重要 手段 ，RocketMQ 的 默认 Log 
仓储 位 置 是 : ${user.home}/Logs/rocketmqLogs，Log 配 置 文件 的 设置 可 
以 通过 JVM 启 动 参数 、 环 境 变 量 、 代 码 中 的 设置 语句 这 三 种 方式 来 配 
置 。 








RocketMQ 日 志 相 关 的 代码 在 org.apache.rocketmq.Client.Log 
ClientLogger 类 中 ， 从 源码 中 可 以 看 到 所 有 的 配置 选项 。 比 如 想 更 改 
RocketMQ Client 的 Log level， 可 以 通过 -Drocketmq.Client.LogLevel 来 设 
置 ， 或 者 在 程序 启动 时 使 用 
System.setProperty ("rocketmg.Client.LogLevel", "WARN") 来 设置 。 





RocketMQ 的 Log 实 现 是 基于 slf4j 的 ， 支 持 Logback、Log4j。 
Client 里 已 经 有 Logback 的 相关 包 ， 可 以 直接 使 用 Logback。 我 
们 可 以 通过 Logback 的 配置 文件 对 日 志 进 行 细 粒度 的 控制 。 


接 下 来 以 一 个 maven 项 目 为 例 ， 具 体 说 明 如 何 使 用 自 定 义 的 Log 配 


首先 需要 把 rocketmq.Client.Log.loadconfig 参 数 设 置 为 false， 可 以 在 
程序 中 使 用 
System.setProperty ("rocketmq.Client.Log.loadconfig", "false") 语句 ， 或 
者 在 JVM 局 动 时 使 用 -D 参 数 来 设置 。 然 后 把 Logback.xml 放 到 maven 项 目 
的 resources 文 件 夹 下 。 在 Logback.xml 示 例 配置 里 ， 在 原 有 RocketMQ 日 
志 的 基础 上 ， 增 加 了 STDOUT 输 出 ， 这 样 可 以 把 RocketMQ 的 日 志 输 出 
到 应 用 系统 console 中 ， 便 于 调试 时 发 现 问 题 ， 如 代码 清单 3-12 所 示 。 


代码 清单 3-12 ”Logback.xml 示 例 





<configuration> 
<appender name="RocketmqClientAppender" 
class="ch.qos.Logback.core.rolling.RollingFileAppender"> 

<file>/Users/mark.yky/IdeaProjects/mqClientest/Logs/rocketmq_Client. Log</fi 

<append>true</append> 

<rollingPolicy class="ch.qos.Logback.core.rolling.FixedwWindow-RollingPolicy' 
<fileNamePattern>/Users/mark.yky/IdeaProjects/mqClientest/otherdays/rock 
</fileNamePattern> 
<minIndex>1</minIndex> 


<maxIndex>20</maxIndex> 
</rollingPolicy> 
<triggeringPolicy 
class="ch.qos.Logback.core.rolling.SizeBasedTriggeringPolicy"> 
<maxFileSize>100MB</maxFileSize> 
</triggeringPolicy> 
<encoder> 
<pattern>%d{yyy-MM-dd HH:mm:ss,GMT+8} %p %t - %m%n</pattern> 
<charset class="java.nio.charset.Charset">UTF-8</charset> 
</encoder> 
</appender> 
<appender name="STDOUT" class="ch.qos.Logback.core.ConsoleAppender "> 
<layout class="ch.qos.Logback.classic.PatternLayout"> 
<Pattern> 
%d{yyy-MM-dd HH:mm:ss, GMT+8} %p %t - %m%n 
</Pattern> 
</layout> 
</appender> 
<Logger name="RocketmqCommon" additivity="false"> 
<level value="DEBUG"/> 
<appender-ref ref="RocketmqClientAppender'"/> 
</Logger> 
<Logger name="RocketmqRemoting" additivity="false"> 
<level value="DEBUG"/> 
<appender-ref ref="RocketmqClientAppender'"/> 
</Logger> 
<Logger name="RocketmqClient" additivity="false"> 
<level value="DEBUG"/> 
<appender-ref ref="RocketmqClientAppender"/> 
<appender-ref ref="STDOUT"/> 
</Logger> 
</configuration> 








有 了 自 定义 的 Log 配 置 ， 就 可 以 根据 实际 情况 ， 设 置 每 个 模块 的 输 
出 Level， 或 者 把 日 志和 输出 到 特定 的 位 置 。 有 具体 的 设置 方法 可 以 参考 
Logback 的 日 志 配 置 文 
#4: https://Logback.qos.ch/manual/configuration.html 。 


3.5 ”本 章 小 结 


对 消息 队列 使 用 者 来 说 ，Consumer 和 Producer 是 打交道 最 多 的 两 个 
类 型 。 本 章 详 细 介 绍 了 两 种 类 型 的 Consumer 和 一 种 类 型 的 Producer， 用 
户 在 使 用 的 时 候 基 于 业务 需求 来 选择 合适 的 类 型 。 最 后 重点 介绍 了 
Offset 和 Log， 了 解 Offset 机 制 是 正确 使 用 RocketMQ 的 基础 ， 合 理 使 用 
Log 可 以 大 幅 提 高 开发 、 调 试 的 效率 。 下 一 章 将 介绍 RocketMQ 的 
NameServer 模 块 。 





第 4 草 ” 分 布 式 消息 队列 的 协调 者 


对 于 一 个 消息 队列 集群 来 说 ， 系 统 由 很 多 台 机 器 组 成 ， 每 个 机 器 的 
角色 、IP 地 址 都 不 相同 ， 而 且 这 些 信息 是 变动 的 。 这 种 情况 下 ， 如 果 一 
个 新 的 Producer 或 Consumer 加 入 ， 怎 么 配置 连接 信息 呢 ?NameServer 的 
存在 主要 是 为 了 解决 这 类 问题 ， 由 NameServer 维 护 这 些 配置 信息 、 状 态 
信息 ， 其 他 角色 都 通过 NameServer 来 协同 执行 。 





4.1 NameServer 的 功能 


NameServer 是 整个 消息 队列 中 的 状态 服务 器 ， 集 群 的 各 个 组 件 通 过 
它 来 了 解 全 局 的 信息 。 同 时 ， 各 个 角色 的 机 器 都 要 定期 间 NameServer 上 
报 自己 的 状态 ， 超 时 不 上 报 的 话 ，NameServer 会 认为 某 个 机 器 出 故障 不 
可 用 了 ， 其 他 的 组 件 会 把 这 个 机 器 从 可 用 列表 里 移 除 。 


NamServer 可 以 部 署 多 个 ， 相 互 之 间 独 立 ， 其 他 角色 同时 向 多 个 
NameServer 机 器 上 报 状 态 信息 ， 从 而 达到 热 备 份 的 目的 。NameServer 本 
身 是 无 状态 的 ， 也 就 是 说 NameServer 中 的 Broker、Topic 等 状态 信息 不 会 
持久 存储 ， 都 是 由 各 个 角色 定时 上 报 并 存储 到 内 存 中 的 〈NameServer 文 
持 配 置 参 数 的 持久 化 ， 一 般 用 不 到 ) 。 


4.1.1 集群 状态 的 存储 结构 


在 org.apache.rocketmq.namesrv.routeinfo 的 RouteInfoManager 类 中 ， 


有 五 个 变量 ， 集 群 的 状态 就 保存 在 这 五 个 变量 中 。 





‘private final HashMap<String/*topic*/, 
List<QueueData>>topicQueueTable 


topicQueueTableia | at 构 的 Key 是 Topic 的 名 称 ， 它 存储 了 所 有 
Topic 的 属性 信息 。Value 是 个 QueueData 队 列 ， 队 里 的 长 度 等 于 这 个 
Topic 数 据 存 储 的 Master Broker 的 个 数 ，QueueData 里 存储 着 Broker 的 名 
称 、 读 写 queue 的 数量 、 同 步 标识 等 





‘private final HashMap<String/*BrokerName*/, BrokerData>Broker- 
AddrTable 


以 BrokerName 为 索引 ， 相 同名 称 的 Broker 可 能 存在 多 台 机 器 ， 一 个 
Master 和 多 个 Slave。 这 个 结构 存储 着 一 个 BrokerName 对 应 的 属性 信息 ， 
包括 所 属 的 Cluster 名 称 ， 一 个 Master Broker 和 多 个 Slave Broker 的 地 址 信 
A. 


‘private final HashMap<String/*ClusterName*/, 
Set<String/*BrokerName*/>>ClusterAddrTable 


存储 的 是 集群 中 Cluster 的 信息 ， 结 果 很 简单 ， 就 是 一 个 Cluster 名 称 
对 应 一 个 由 BrokerName 组 成 的 集合 。 


‘private final HashMap<String/*BrokerAddr*/, 
BrokerLiveInfo>Broker-LiveTable 


这 个 结构 和 BrokerAddrTable 有 关系 ， 但 是 内 容 完 全 不 同 ， 这 个 结构 
的 Key 是 BrokerAddr， 世 就 是 对 应 着 一 台 机 器 ，BrokerAddrTable 中 的 
Key 是 BrokerName， 多 个 机 器 的 BrokerName 可 以 相同 。BrokerLiveTable 
存储 的 内 容 是 这 人 台 Broker 机 器 的 实时 状态 ， 包 括 上 次 更 新 状态 的 时 间 
鹤 ，NameServer 会 定期 检查 这 个 时 间 戳 ， 超 时 没有 更 新 就 认为 这 个 
Broker 无 效 了 ， 将 其 从 Broker 列 表 里 清除 。 


‘private final HashMap<String/*BrokerAddr*/, List<String>/*Filter 
Server*/>filterServerTable 


Filter Server 是 过 滤 服 务 器 ， 是 RocketMQ 的 一 种 服务 端 过 滤 方 式 ， 
一 个 Broker 可 以 有 一 个 或 多 个 Filter Server。 这 个 结构 的 Key 是 Broker 的 
地 址 ，Value 是 和 这 个 Broker 关 联 的 多 个 Filter Server 的 地 址 。 


从 上 面 这 五 个 变量 的 定义 ， 可 以 清楚 地 看 出 各 个 组 件 的 状态 是 如 何 
存储 的 ，NameServer 的 主要 工作 就 是 维护 这 五 个 变量 中 存储 的 信息 。 











4.1.2 ”状态 维护 逻辑 


本 节 基 于 源码 分 析 NameServer 如 何 维护 各 个 Broker 的 实时 状态 ， 如 
何 根据 Broker 的 情况 更 新 各 种 集群 的 属性 数据 。 因 为 其 他 角色 会 主动 问 
NameServer 上 报 状态 ， 所 以 NameServer 的 主要 逻辑 在 DefaultRequest- 
Processors 中 ， 根 据 上 报 消 息 里 的 请 求 码 做 相应 的 处 理 ， 更 新 存储 的 对 
应 信息 。 此 外 ， 连 接 断 开 的 事件 也 会 触发 状态 更 新 ， 有 具体 逻辑 在 
org.apache.rocketmq.namesrv.routeinfo 的 BrokerHousekeepingService 类 


中 ， 如 代码 清单 4-1 所 示 。 
代码 清单 4-1 Channel 断 开 触发 的 回调 函数 





@Override 
public void onChannelClose(String remoteAddr, Channel channel) { 
this.namesrvController.getRouteInfoManager().onChannelDestroy (remoteAddr, chanr 


@Override 
public void onChannelException(String remoteAddr, Channel channel) { 
this.namesrvController.getRouteInfoManager().onChannelDestroy (remoteAddr, chanr 


} 

@Override 

public void onChannelIdle(String remoteAddr, Channel channel) { 
this.namesrvController.getRouteInfoManager().onChannelDestroy (remoteAddr, chanr 





“4NameServer fll Broker HJ 4 2 $4 VA Ja, onChannelDestroy efi 2 
会 被 调用 ， 把 这 个 Broker 的 信息 清理 出 去 。 


NameServer 还 有 定时 检查 时 间 惟 的 罗 辑 ，Broker 向 NameServer 发 送 
的 心跳 会 更 新 时 间 惟 ， 当 NameServer 检 查 到 时 间 惟 长 时 间 没 有 更 新 后 ， 
便 会 触发 清理 逻辑 ， 如 代码 清单 4-2 所 示 。 


代码 清单 4-2 ”定时 Check Broker 的 状态 





this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
NamesrvController.this.routeInfoManager .scanNotActiveBroker(); 


}, 5, 10, TimeUnit.SECONDS); 





从 代码 可 以 看 出 是 每 10 秒 检查 一 次 ， 时 间 戳 超过 2 分 钟 则 认为 
Broker 已 失效 。 


4.2 各 个 角色 间 的 交互 流程 


下 面 从 Topic 的 创建 入 手 ， 结 合 源 码 分 析 一 下 NameServer 如 何 和 其 
他 各 个 组 件 交 互 ， 以 及 NameServer 存 储 的 元 数据 内 容 的 具体 含义 。 


创建 Topic 的 代码 是 在 org.apache.rocketmdq.tools.command.topic 里 的 
UpdateTopicSubCommand 类 中 ， 创 建 Topic 的 命令 是 updateTopic 如 代码 
清单 4-3 所 示 。 


代码 清单 4-3 updateTopic 的 选项 





Option("b", "BrokerAddr", true, "create topic to which Broker"); 

Option("c", "ClusterName", true, "Create topic to which Cluster"); 

Option("t", "topic", true, "topic name"); 

Option("r", "readQueueNums", true, "set read queue nums"); 

Option("w", "writeQueueNums", true, "set write queue nums"); 

Option("p", "perm", true, "set topic's permission(2|4|6), intro[2:W 4:R; 6:RW]"); 
Option("o", "order", true, "set topic's order(true|false"); 

Option("u", "unit", true, "is unit topic (true|false"); 

Option("s", "hasUnitSub", true, "has unit sub (true|false"); 





其 中 b 和 c 参 数 比 较 重 要 ， 而 且 他 们 俩 只 有 一 个 会 起 作用 〈-b 优 
先 ) ，b 参 数 指定 在 哪个 Broker 上 创建 本 Topic 的 Message Queue, c#2L 
表示 在 这 个 Cluster 下 面 所 有 的 Master 的 Message 
Queue， 从 而 达到 高 可 用 性 的 目的 。 有 具体 的 创建 动作 是 通过 发 送 命令 触 
发 的 ， 如 代码 清单 4-9 所 示 。 


代码 清单 4-4 _ updateTopic 的 命令 








CreateTopicRequestHeader requestHeader = new CreateTopicRequestHeader ( ); 
requestHeader.setTopic(topicConfig.getTopicName()); 
requestHeader.setDefaultTopic(defaultTopic) ; 

requestHeader . setReadQueueNums(topicConfig.getReadQueueNums() ) ; 
requestHeader.setwriteQueueNums(topicConfig.getWriteQueueNums()); 
requestHeader.setPerm(topicConfig.getPerm()); 
requestHeader.setTopicFilterType(topicConfig.getTopicFilterType().name()); 
requestHeader .setTopicSysFlag(topicConfig.getTopicSysFlag()); 
requestHeader.setOrder(topicConfig.isOrder()); 


RemotingCommand request = RemotingCommand.createRequestCommand(RequestCode. UPDATE_/ 





创建 Topic 的 命令 被 发 往 对 应 的 Broker，Broker 接 到 创建 Topic 的 请 
求 后 ， 执 行 具体 的 创建 逻辑 ， 如 代码 清单 4-5 所 示 。 


代码 清单 4-5”Broker 处 理 updateTopic 命 令 





private RemotingCommand updateAndCreateTopic(ChannelHandlerContext ctx, Remotinc 





this.BrokerController.getTopicConfigManager().updateTopicConfig(topicConfig); //## 
this.BrokerController.registerBrokerAll(false, true); // 向 NameServer 发 送 regis 
return null; 


} 














注意 最 后 一 步 是 向 NameServer 发 送 注 册 信 息 ，NameServer 完 成 创建 
Topic 的 逻辑 后 ， 其 他 客户 端 才能 发 现 新 增 的 Topic， 相 关 逻 辑 在 
org.apache.rocketmq.namesrv.routeinfo 的 RouteInfoManager 类 中 的 
registerBroker 函 数 里 ， 首 先 更 新 Broker 信 息 ， 然 后 对 每 个 Master 角 色 的 
Broker， 创 建 一 个 QueueData 对 象 。 如 果 是 新 建 Topic， 就 是 添加 
QueueData 对 象 ， 如 果 是 修改 Topic， 就 是 把 旧 的 QueueData 删 除 ， 加 入 
新 的 QueueData。 


4.2.2 ”为 何不 用 ZooKeeper 


ZooKeeper 是 Apache 的 一 个 开源 软件 ， 为 分 布 式 应 用 程序 提供 协调 
服务 。 那 为 什么 RocketMQ 要 目 己 造 轮子 ， 开 发 集群 的 管理 程序 呢 ? 答 
案 是 ZooKeeper 的 功能 很 强大 ， 包 括 自 动 Master 人 选举 等 ，RocketMQ 的 架 
构 设 计 决 定 了 它 不 需要 进行 Master 选 举 ， 用 不 到 这 些 复杂 的 功能 ， 只 需 
要 一 个 轻 量 级 的 元 数据 服务 器 就 足够 了 。 





中 间 件 对 稳定 性 要 求 很 高 ，RocketMQ 的 NameServer 只 有 很 少 的 代 
容易 维护 ， 所 以 不 需要 再 依赖 男 一 个 中 间 件 ， 从 而 减少 整体 维护 成 


4.3 ”底层 通信 机 制 





分 布 式 系统 各 个 角色 间 的 通信 效率 很 关键 ， 通 信 效 率 的 高 低 直 接 影 


响 系 统 性 能 ， 基 于 Socket 实 现 一 个 高 效 的 TCP 通 信 协 议 是 很 有 挑战 的 ， 
本 节 介 绍 RocketMQ 是 如 人 何 解决 这 个 问题 的 。 


4.3.1 Remoting? 





RocketMQ 的 通信 相关 代码 在 Remoting 模 块 里 ， 先 来 看 看 主要 类 结 
构 ， 如 图 4-1 所 示 。 


RemotingService 


+ start 
+ shutDown 
+ registerRPCHook 









RemotingServer 


+ registerProcessor + registerProcessor 

+ invokeSync + invokeSync 

+ invokeAsync x + invokeAsync 

+ invokeOneway NettyRemotingAbstract + invokeOneway 

+ localListenPort + processRequestCommand + updateNameServerAddressList 
+ invokeSyncImpl 


+ invokeAsyncImpl 
+ NettyEventExecutor 


RemotingClient 












NettyRemotingServer NettyRemotingClient 
et es 


图 4-1 ”Remoting 模 块 的 类 继承 关系 


RemotingService 为 最 上 层 接口 ， 定 义 了 三 个 方法 : 





‘void start () ; 

-void shutdown () ; 

-void registerRPCHook (RPCHook rpcHook) ; 

RemotingClient 和 RemotingServer 继 承 RemotingService 接 口 ， 并 增加 


了 自己 特有 的 方法 。RemotingClient 的 主要 函数 定义 如 代码 清单 4-6 所 
示 。 





代码 清单 4-6 RemotingClient 主 要 函数 定义 





void registerProcessor(final int requestCode, final NettyRequestProcessor processor, 


RemotingCommand invokeSync(final String addr, final RemotingCommand request, final ] 
void invokeAsync(final String addr, final RemotingCommand request, final long timeot 
void invokeOneway(final String addr, final RemotingCommand request, final long timec 
void updateNameServerAddressList(final List<String> addrs); 





然后 看 看 具体 的 实现 类 ，NettyRemotingClient 和 
NettyRemotingServer 分 别 实现 了 RemotingClient 和 RemotingServer， 而 且 
都 继承 了 NettyRemoting-Abstract 类 。 


通过 上 面 的 封装 ，RocketMQ 各 个 模块 间 的 通信 ， 可 以 通过 发 送 统 
一 格式 的 自 定 义 消 息 〈RemotingCommand) 来 完成 ， 各 个 模块 间 的 通信 
实现 简洁 明了 。 


比如 NameServer 模 块 中 ，NameServerController 有 一 个 
remotingServer 变 量 ，NameServer 在 启动 时 初始 化 各 个 变量 ， 然 后 启动 
remotingServer 即 可 ， 剩 下 NameServer 要 做 的 是 专心 实现 处 理 
RemotingCommand 的 逻辑 ， 如 代码 清单 4-7 所 示 。 


代码 清单 4-7 “NameServer 处 理 主流 程 代码 





@Override 
public RemotingCommand processRequest(ChannelHandlerContext ctx, RemotingCommand rec 
if (log.isDebugEnabled()) { 
log.debug("receive request, {} {} {}", 
request .getCode(), 
RemotingHelper .parseChannelRemoteAddr(ctx.channel()), 
request); 


} 
switch (request.getCode()) { 
case RequestCode.PUT_KV_CONFIG: 
return this.putKVConfig(ctx, request); 
case RequestCode.GET_KV_CONFIG: 
return this.getKVConfig(ctx, request); 
case RequestCode.DELETE_KV_CONFIG: 
return this.deletekKVConfig(ctx, request); 
case RequestCode.REGISTER_BROKER: 
Version brokerVersion = MQVersion.value2Version(request.getVersion()) 
if (brokerVersion.ordinal() >= MQVersion.Version.V3_0_11.ordinal()) { 
return this.registerBrokerwithFilterServer(ctx, request); 
} else { 
return this.registerBroker(ctx, request); 


rd 


} 
case RequestCode.UNREGISTER_BROKER: 

return this.unregisterBroker(ctx, request); 
case RequestCode.GET_ROUTEINTO_BY_TOPIC: 

return this.getRouteInfoByTopic(ctx, request); 
case RequestCode.GET_BROKER_CLUSTER_INFO: 

return this.getBrokerClusterInfo(ctx, request); 
case RequestCode.WIPE_WRITE_PERM_OF_BROKER: 

return this.wipewritePermOfBroker(ctx, request); 
case RequestCode.GET_ALL_TOPIC_LIST_FROM_NAMESERVER: 

return getAllTopicListFromNameserver(ctx, request); 








case RequestCode.DELETE_TOPIC_IN_NAMESRV: 
return deleteTopicInNamesrv(ctx, request); 
case RequestCode.GET_KVLIST_BY_NAMESPACE: 
return this.getKVListByNamespace(ctx, request); 
case RequestCode.GET_TOPICS_BY_CLUSTER: 
return this.getTopicsByCluster(ctx, request); 
case RequestCode.GET_SYSTEM_TOPIC_LIST_FROM_NS: 
return this.getSystemTopicListFromNs(ctx, request); 
case RequestCode.GET_UNIT_TOPIC_LIST: 
return this.getUnitTopicList(ctx, request); 
case RequestCode.GET_HAS UNIT_SUB_TOPIC_LIST: 
return this.getHasUnitSubTopicList(ctx, request); 
case RequestCode.GET_HAS_UNIT_SUB_UNUNIT_TOPIC_LIST: 
return this.getHasUnitSubUnUnitTopicList(ctx, request); 
case RequestCode.UPDATE_NAMESRV_CONFIG: 
return this.updateConfig(ctx, request); 
case RequestCode.GET_NAMESRV_CONFIG: 
return this.getConfig(ctx, request); 
default: 
break; 











return null; 





在 Consumer 的 源码 中 ， 获 取消 息 的 底层 通信 部 分 同样 发 送 一 个 
RemotingCommand 请 求 ， 返 回 的 response 也 是 个 RemotingCommand 类 


型 ， 如 代码 清单 4-8 所 示 。 
代码 清单 4-8 Consumer 请 求 消息 底层 实现 代码 











private PullResult pullMessageSync(// 
final String addr, // 1 
final RemotingCommand request, // 2 
final long timeoutMillis// 3 

) throws RemotingException, InterruptedException, MQBrokerException { 
RemotingCommand response = this.remotingClient.invokeSync(addr, request, timeout 
assert response != null; 
return this.processPullResponse(response); 





从 源码 中 可 以 看 出 ，RocketMQ 中 复杂 的 通信 过 程 ， 被 
RemotingCommand 统 一 起 来 ， 大 部 分 的 逻辑 都 是 通过 发 送 、 接 受 并 处 理 
Command 来 完成 的 。 





4.3.2 ”协议 设计 和 编 解 码 


RocketMQ 自 己 定义 了 一 个 通信 协议 ， 使 得 模块 间 传 输 的 二 进 制 消 
恩 和 有 意义 的 内 容 之 间 互 相 转 换 。 协 议 格式 如 图 4-2 所 示 。 


————— J : 


length header length 
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图 4-2 ”RocketMQ 的 通信 协议 


1) 第 一 部 分 是 大 端 4 个 字 市 整数 ， 值 等 于 第 二 、 三 、 四 部 分 长 度 的 
总 和 ; 


2) 第 二 部 分 是 大 病 4 个 字 市 整数 ， 值 等 于 第 三 部 分 的 长 度 ; 
3) 第 三 部 分 是 通过 Json 序 列 化 的 数据 ; 
4) 第 四 部 分 是 通过 应 用 目 定 义 二 进 制 序列 化 的 数据 。 


消息 的 解码 过 程 在 RemotingCommand 的 decode 函 数 里 ， 如 代码 清单 
4-9 所 示 。 


代码 清早 4-9 ” 消 居 解码 函数 








public static RemotingCommand decode(final ByteBuffer byteBuffer) { 
int length = byteBuffer. limit(); 
int oriHeaderLen = byteBuffer.getInt(); 
int headerLength = getHeaderLength(oriHeaderLen) ; 
byte[] headerData = new byte[headerLength]; 
byteBuffer.get(headerData) ; 
RemotingCommand cmd = headerDecode(headerData, getProtocolType (oriHeaderLen) ); 
int bodyLength = length - 4 - headerLength; 
byte[] bodyData = null; 
if (bodyLength > 0) { 
bodyData = new byte[bodyLength]; 
byteBuffer.get(bodyData) ; 


} 
cmd.body = bodyData; 
return cmd; 


一 


对 应 的 消息 编码 过 程 在 RemotingCommand 的 encode 函 数 中 ， 如 代码 
清单 4-10 所 示 。 


代码 清单 4-10 ”消息 编码 函数 





public ByteBuffer encode() { 
// 1> header length size 
int length = 4; 
// 2> header data length 
byte[] headerData = this.headerEncode(); 
length += headerData.length; 
// 3> body data length 
if (this.body != null) { 
length += body.length; 


} 
ByteBuffer result = ByteBuffer.allocate(4 + length); 
// length 
result.putInt(length); 
// header length 
result.put(markProtocolType(headerData.length, serializeTypeCurrentRPC) ); 
// header data 
result.put(headerData) ; 
// body data; 
if (this.body != null) { 
result.put(this.body) ; 


} 
result.flip(); 
return result; 


4.3.3 Netty 


RocketMQ 是 基于 Netty 库 来 完成 RemotingServer 和 RemotingClient 具 
体 的 通信 实现 的 ，Netty 是 个 事件 驱动 的 网 络 编程 框架 ， 它 屏 菩 了 Java 
Socket、NIO 等 复杂 细节 ， 用 户 只 需 用 好 Netty， 就 可 以 实现 一 个 “网 络 编 
程 专家 + 并 发 编程 专家 ?水平 的 Server、Client 网 络 程序 。 应 用 Netty 有 一 
定 的 门槛 ， 需 要 了 解 它 的 EventLoopGroup、Channel、Handler 模 型 以 及 
各 种 具体 的 配置 。RocketMQ 利 用 Netty 实 现 的 通信 类 是 
NettyRemotingServer 和 NettyRemotingClient， 用 户 也 可 以 参考 这 两 个 类 
的 实现 来 学 习 使 用 Netty。 








44 ”本 章 小 结 


本 章 介 绍 了 NameServer 的 功能 ，NameServer 在 RocketMQ 和 集群 中 扮 
演 调度 中 心 的 角色 。 各 个 Producer、Consumer 上 报 自 己 的 状态 上 去 ， 同 
时 从 NameServer 获 取 其 他 角色 的 状态 信息 。NameServer 的 功能 虽然 非常 
重要 ， 但 是 被 设计 得 很 轻 量 级 ， 人 代码 量 少 并 且 几 乎 无 磁盘 存储 ， 所 有 的 
功能 都 通过 内 存 高 效 完 成 。 本 章 还 介绍 了 底层 的 通信 机 制 ，RocketMQ 
基于 Netty 对 底层 通信 做 了 很 好 的 抽象 ， 使 得 通信 功能 逻辑 清晰 ， 代 码 
简单 。Netty 的 介绍 和 具体 的 通信 实现 可 以 查看 第 13 章 。 
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Broker 是 RocketMQ 的 核心 ， 大 部 分 “重量 级 ”工作 都 是 由 Broker 完 成 
的 ， 包 括 接收 Producer 发 过 来 的 消息 、 处 理 Consumer 的 消费 消息 请 求 、 
消息 的 持久 化 存储 、 消 息 的 HA 机 制 以 及 服务 端 过 滤 功 能 等 。 





5.1 消息 存储 和 发 送 


分 布 式 队列 因为 有 高 可 靠 性 的 要 求 ， 所 以 数据 要 通过 磁盘 进行 持久 
化 存储 。 用 磁盘 存储 消 轧 ， 速 度 会 不 会 很 慢 呢 ? Be Ty AL SEIN) PA AMT ea A HEL 
量 的 要 求 吗 ? 


实际 上 上， 磁盘 有 时 候 会 比 你 想象 的 快 很 多 ， 有 时 候 也 会 比 你 想象 的 
慢 很 多 ， 关 键 在 如 何 使 用 ， 使 用 得 当 ， 磁 盘 的 速度 完全 可 以 匹配 上 网 络 
的 数据 传输 速度 。 目 前 的 高 性 能 磁盘 ， 顺 序 写 速度 可 以 达到 600MB/s， 
超过 了 一 般 网 卡 的 传输 速度 ， 这 是 磁盘 比 想 象 的 快 的 地 方 。 但 是 磁盘 随 
机 写 的 速度 只 有 大 概 100KB/s， 和 顺序 写 的 性 能 相差 6000 倍 ! 因为 有 如 
此 巨大 的 速度 差别 ， 好 的 消息 队列 系统 会 比 普 通 的 消息 队列 系统 速度 快 
多 个 数量 级 。 

举 个 例子 ，Linux 操 作 系 统 分 为 “用 户 态 ”和 “内 核 态 ”， 文 件 操作 、 网 
络 操作 需要 涉及 这 两 种 形态 的 切换 ， 免 不 了 进行 数据 复制 ， 一 台 服 务 器 
把 本 机 磁盘 文件 的 内 容 发 送 到 客户 端 ， 一 般 分 为 两 个 步骤; 


1) read (file, tmp_buf, len) ; ， 读 取 本 地 文件 内 容 ; 








2) write (socket, tmp_buf, len) ; ， 将 读 取 的 内 容 通过 网 络 发 送 
Ha 


tmp_buf 是 预先 申请 的 内 存 ， 这 两 个 看 似 简 单 的 操作 ， 实 际 进行 了 4 
次 数据 复制 ， 分 别 是 : 从 磁盘 复制 数据 到 内 核 态 内 存 ， 从 内 核 态 内 存 复 
制 到 用 户 态 内 存 (完成 了 read (file, tmp_buf, len) ) ; 然后 从 用 户 态 
内 存 复制 到 网 络 驱 动 的 内 核 态 内 存 ， 最 后 是 从 网 络 驱 动 的 内 核 态 内 存 复 
制 到 网 卡 中 进行 传输 (完成 write (socket, tmp_buf, len) ) 。 


通过 使 用 mmap 的 方式 ， 可 以 省 去 向 用 户 态 的 内 存 复 制 ， 提 高 速 
度 。 这 种 机 制 在 Java 中 是 通过 MappedByteBuffer 实 现 的 ， 具 体 可 以 参考 
Java 7 的 文 
$4: https://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.ht 
。RocketMQ 充 分 利用 了 上 述 特性 ， 也 就 是 所 谓 的 “ 零 拷贝 "技术 ， 提 高 
消息 存盘 和 网 络 发 送 的 速度 。 











5.2 ”消息 存储 结构 


RocketMQ 的 具体 消息 存储 结构 是 怎样 的 呢 ? 如 何 尽 量 保证 顺序 写 
的 呢 ? 先 来 看 看 整体 的 架构 图 ， 如 图 5-1 所 示 。 


RocketMQ 消 息 的 存储 是 由 ConsumeQueue 和 CommitLog 配 合 完成 
的 ， 消 息 真 正 的 物理 存储 文件 是 CommitLog，ConsumeQueue 是 消息 的 
逻辑 队列 ， 类 似 数据 库 的 索引 文件 ， 存 储 的 是 指 问 物理 存储 的 地 址 。 
个 Topic 下 的 每 个 Message Queue 都 有 一 个 对 应 的 ConsumeQueue 文 件 。 文 
件 地 址 在 
${$storeRoot}\consumequeue\${topicName }\${queueld}\$ {fileName}. 


ConsumeQueue 








(Store Offset in CommitLog) 


SendjMessage 
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ConsumeQueue Record Format 


图 5-1 RocketMQ 的 存储 结构 图 


CommitLog 以 物理 文件 的 方式 存放 ， 每 台 Broker 上 的 CommitLog 被 
本 机 器 所 有 ConsumeQueue 共 享 ， 文 件 地 址 : 


${user.home}\store\${commitlog}\${fileName}. ÆCommitLog F, —~* 
消息 的 存储 长 度 是 不 固定 的 ，RocketMQ 采 取 一 些 机 制 ， 尽 量 同 
CommitLog 中 顺序 写 ， 但 是 随机 读 。ConsumeQueue 的 内 容 也 会 被 写 到 
磁盘 里 作 持 和 久 存 储 。 


存储 机 制 这 样 设 计 有 以 下 几 个 好 处 : 
1) CommitLog 顺 序 写 ， 可 以 大 大 提高 写 入 效率 。 


2) 虽然 是 随机 读 ， 但 是 利用 操作 系统 的 pagecache 机 制 ， 可 以 批量 
地 从 磁盘 读 取 ， 作 为 cache 存 到 内 存 中 ， 加 速 后 续 的 读 取 速度 。 


3) 为 了 保证 完全 的 顺序 写 ， 需 要 ConsumeQueue 这 个 中 间 结 构 ， 
为 ConsumeQueue 里 只 存 偏 移 量 信息 ， 所 以 尺寸 是 有 限 的 ， 在 实际 情况 
中 ， 大 部 分 的 ConsumeQueue 能 够 被 全 部 读 入 内 存 ， 所 以 这 个 中 间 结 构 
的 操作 速度 很 快 ， 可 以 认为 是 内 存 读 取 的 速度 。 此 外 为 了 保证 
CommitLog 和 ConsumeQueue 的 一 致 性 ，CommitLog 里 存储 了 Consume 
Queues, Message Key、Tag 等 所 有 信息 ， 即 使 ConsumeQueue 丢 失 ， 也 
可 以 通过 commitLog 完 全 恢复 出 来 。 


如 图 5-2 所 示 是 一 个 Broker 在 文件 系统 中 存储 的 各 个 文件 。 我 们 可 以 
看 到 commitlog 文 件 夹 、consumequeue 文 件 夹 ， 还 有 在 config 文 件 夹 中 
Topic、Consumer 的 相关 信息 。 最 下 面 那 个 文件 夹 index 存 的 是 索引 文 
件 ， 这 个 文件 用 来 加 快 消息 查询 的 速度 。 

















+—— abort 

+—— checkpoint 

+—— commitlog 

| Ut —90000000000000000000 
+—— config 

| į—— consumerFilter.json 

| “上 | 一 一 consumerFilterjson.bak 

| “上 | 一 一 consumerOffset.json 

| /— consumerOffset.json.bak 

| [| — delayOffset.json 

| į—— delayOffset.json.bak 

| |— subscriptionGroup.json 

| į—— subscriptionGroup.json.bak 

| “| 一 topics.json 

| “一 一 topics.json.bak 

I consumequeue 

| Ut testCreateTopic3 

| -一 一 和 

| | 00000000000000000000 
| 1 

| -一 一 00000000000000000000 
+—— index 

| bt —20180116144023027 


图 5-2 ”RocketMQ 的 Broker 机 器 磁盘 上 的 文件 存储 结构 


5.3 ”高 可 用 性 机 制 


RocketMQ 分 布 式 集群 是 通过 Master 和 Slave 的 配合 达到 高 可 用 性 
的 ， 首 先 说 一 下 Master 和 Slave 的 区 别 : 在 Broker 的 配置 文件 中 ， 参 数 
brokerId 的 值 为 0 表明 这 个 Broker 是 Master， 大 于 0 表明 这 个 Broker 是 
Slave， 同 时 brokerRole 参 数 也 会 说 明 这 个 Broker 是 Master 还 是 Slave。 
Master 角 色 的 Broker 支 持 读 和 写 ，Slave 角 色 的 Broker 仅 支持 读 ， 也 就 是 
Producer 只 能 和 Master 角 色 的 Broker 连 接 写 入 消息 ;Consumer 可 以 连接 
Master 角 色 的 Broker， 也 可 以 连接 Slave 角 色 的 Broker 来 读 取消 息 。 


在 Consumer 的 配置 文件 中 ， 并 不 需要 设置 是 从 Master 读 还 是 从 Slave 
该 ， 当 Master 不 可 用 或 者 繁忙 的 时 候 ，Consumer 会 被 自动 切换 到 从 Slave 
读 。 有 了 和 目 动 切换 Consumer 这 种 机 制 ， 当 一 个 Master 角 色 的 机 器 出 现 故 
障 后 ，Consumer 仍 然 可 以 从 Slave 读 取消 息 ， 不 影响 Consumer 程 序 。 这 
就 达到 了 消费 端的 高 可 用 性 。 


如 何 达 到 发 送 端的 高 可 用 性 呢 ? 在 创建 Topic 的 时 候 ， 把 Topic 的 多 
个 Message Queue 创 建 在 多 个 Broker 组 上 (相同 Broker 名 称 ， 不 同 
brokerId 的 机 器 组 成 一 个 Broker 组 ) ， 这 样 当 一 个 Broker 组 的 Master 不 可 
用 后 ， 其 他 组 的 Master 仍 然 可 用 ，Producer 仍 然 可 以 发 送 消息 。 
RocketMQ 目 前 还 不 支持 把 Slave 自 动 转 成 Master， 如 果 机 器 资源 不 足 ， 
需要 把 Slave 转 成 Master， 则 要 手动 停止 Slave 角 色 的 Broker， 更 改 配置 文 
件 ， 用 新 的 配置 文件 启动 Broker。 





5.4 fei 2 Mill sak Be Ml sk 


RocketMQ 的 消息 是 存储 到 磁盘 上 的 ， 这 样 既 能 保证 断 电 后 恢复 ， 
又 可 以 让 存储 的 消息 量 超出 内 存 的 限制 。RocketMQ 为 了 提高 性 能 ， 会 
尽 可 能 地 保证 磁盘 的 顺序 写 。 消 息 在 通过 Producer 写 入 RocketMQ 的 时 
候 ， 有 两 种 写 破 盘 方式 ， 下 面 逐 一 介绍 。 


异步 刷 盘 方式 : 在 返回 写成 功 状 态 时 ， 消 妃 可 能 只 是 被 写 入 了 入 
存 的 PAGECACHE， 写 操作 的 返回 快 ， 吞 吐 量 大 ， 当 内存 里 的 消息 量 积 
球 到 一 定 程度 时 ， 统 一 触发 写 磁盘 动作 ， 快 速写 入 。 


.同步 刷 盘 方式 : ADRS ROSIN, ROARS AW. H 
体 流 程 是 ， 消 息 写 入 内 存 的 PAGECACHE 后 ， 立 刻 通 知 刷 盘 线 程 刷 盘 ， 
然后 等 待 刷 盘 完成 ， 刷 盘 线 程 执行 完成 后 唤醒 等 待 的 线程 ， 返 回 消 息 写 
成 功 的 状态 。 











Producer Producer 


\/ 





\/ 





异步 刷 盘 


图 5-3 ”同步 刷 盘 和 异步 刷 盘 


同步 刷 盘 还 是 异步 刷 盘 ， 是 通过 Broker 配 置 文件 里 的 ftushDiskType 
参数 设置 的 ， 这 个 参数 被 配置 成 YNC_FLUSH、ASYNC _ FLUSH 中 的 


| 


55 同步 复制 和 异步 复制 


如 果 一 个 Broker 组 有 Master 和 Slave， 消 息 需 要 从 Master 复 制 到 Slave 
上 ， 有 同步 和 异步 两 种 复制 方式 。 同 步 复 制 方式 是 等 Master 和 Slave 均 写 
成 功 后 才 反馈 给 客户 端 写成 功 状 态 ， 有 异步 复制 方式 是 只 要 Master 写 成 功 
即 可 反馈 给 客户 端 写成 功 状 态 。 


这 两 种 复制 方式 各 有 优 务 ， 在 异步 复制 方式 下 ， 系 统 拥 有 较 低 的 延 
人 迟 和 较 高 的 吞吐 量 ， 但 是 如 果 Master 出 了 故障 ， 有 些 数据 因为 没有 被 写 
入 Slave， 有 可 能 会 丢失 ; 在 同步 复制 方式 下 ， 如 果 Master 出 故障 ， 
Slave 上 有 全 部 的 备份 数据 ， 容 易 恢复 ， 但 是 同步 复制 会 增 大 数据 写 入 
延迟 ， 降 低 系统 吞吐 量 。 


同步 复制 和 异步 复制 是 通过 Broker 配 置 文件 里 的 brokerRole 参 数 进 
行 设 置 的 ， 这 个 参数 可 以 被 设置 成 ASYNC_MASTER、 
SYNC MASTER、SLAVE 三 个 值 中 的 一 个 。 


实际 应 用 中 要 结合 业务 场景 ， 合 理 设置 刷 盘 方式 和 主 从 复制 方式 ， 
尤其 是 SYNC_FLUSH 方 式 ， 由 于 频繁 地 触发 磁盘 写 动 作 ， 会 明显 降低 
性 能 。 通 常情 况 下 ， 应 该 把 Master 和 Save 配 置 成 ASYNC_FLUSH 的 刷 盘 
方式 ， 主 从 之 间 配 置 成 SYNC_MASTER 的 复制 方式 ， 这 样 即 使 有 一 台 
机 器 出 故障 ， 仍 然 能 保证 数据 不 丢 ， 是 个 不 错 的 选择 。 












































5.6 ”本章 小 结 


本 章 介 绍 了 RocketMQ 消 恩 队 列 实现 的 难点 及 核心 ， 即 “队列 ”本 续 
的 实现 ， 基 于 磁盘 做 一 个 读 写 效率 高 的 队列 并 非 易 事 ， 实 现 不 好 就 会 使 
磁盘 操作 成 为 整个 系统 的 瓶颈 ， 无 法 提升 系统 的 吞吐 量 。RocketMQ 基 
ee 
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多 个 机 器 ， 这 样 当 一 合 机 器 出 故障 后 ， 整 体系 统 依然 可 用 。 这 样 可 靠 性 
和 性 能 能 直接 有 个 权衡 ，RocketMQ 把 选择 权 留 给 用 户 ， 用 户 根 据 具体 
的 业务 场景 来 选择 要 更 高 的 可 靠 性 ， 还 是 要 更 高 的 效率 。 


第 6 章 ”可 徘 性 优先 的 使 用 场景 


本 章 的 重点 是 可 靠 性 ， 解 决 如 何 让 消息 队列 满足 业务 逻辑 需求 ， 同 
时 稳定 、 可 靠 地 长 期 运行 。 


6.1 JIRA 
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下 ， 必 须 保 证 顺序 。 比 如 订单 的 生成 、 付 蒜 、 发 货 ， 这 3 个 消息 必须 按 
顺序 处 理 才 行 。 顺 序 消 息 分 为 全 局 顺序 消 轧 和 部 分 顺序 消 轧 ， 全 局 顺序 
消息 指 某 个 Topic 下 的 所 有 消 妃 都 要 保证 顺序 ;部 分 顺序 消 轧 只 要 保证 
每 一 组 消息 被 顺序 消费 即 可 ， 比 如 上 面 订 单 消息 的 例子 ， 只 要 保证 同一 
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6.1.1 全 局 顺序 消 忌 


RocketMQ 在 默认 情况 下 不 保证 顺序 ， 比 如 创建 一 个 Topic， 默 认 八 
个 写 队 列 ， 八 个 读 队 列 。 这 时 候 一 条 消息 可 能 被 写 入 任意 一 个 队列 里 ; 
在 数据 的 读 取 过 程 中 ， 可 能 有 多 个 Consumer， 每 个 Consumer 也 可 能 局 
动 多 个 线程 并 行 处 理 ， 所 以 消息 被 哪个 Consumer 消 费 ， 被 消费 的 顺序 和 
写 入 的 顺序 是 否 一 致 是 不 确定 的 。 


要 保证 全 局 顺序 消息 ， 需 要 先 把 Topic 的 读 写 队列 数 设置 为 一 ， 然 
后 Producer 和 Consumer 的 并 发 设置 也 要 是 一 。 人 简单 来 说 ， 为 了 保证 整个 
Topic 的 全 局 消息 有 序 ， 只 能 消除 所 有 的 并 发 处 理 ， 各 部 分 都 设置 成 单 
线程 处 理 。 这 时 高 并 发 、 高 吞吐 量 的 功能 完全 用 不 上 了 。 


在 实际 应 用 中 ， 更 多 的 是 像 订单 类 消息 那样 ， 只 需要 部 分 有 序 即 
可 。 在 这 种 情况 下 ， 我 们 经 过 合适 的 配置 ， 依 然 可 以 利用 RocketMQ 局 
并 有 发、 高 厨 吐 量 的 能 























6.1.2 ”部 分 顺序 消 忆 





要 保证 部 分 消息 有 序 ， 需 要 发 送 端 和 消费 端 配 合 处 理 。 在 发 送 端 ， 
要 做 到 把 同一 ee ae Queue; 在 消费 过 程 
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发 送 端 使 用 MessageQueueSelector 类 来 控制 把 消息 发 往 哪 个 Message 
Queue， 如 代码 清单 6-1 所 示 。 


代码 清单 6-1 MessageQueueSelector 示 例 





for (int i = 0; i < 100; i++) { 
int orderId = i; 
//Create a message instance, specifying topic, tag and message body. 
Message msg = new Message("OrderTopic8", tags, "KEY" + i, 
("Hello RocketMQ " +orderId+" "+ i).getBytes(RemotingHelper . DEFAULT_CHARSE1 
SendResult sendResult = Producer.send(msg, new MessageQueueSelector() { 
@Override 
public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) 
System.out.println("queue selector mq nums:"+mqs.size()); 
System.out.println("msg info:"+msg.toString()); 
for(MessageQueue mq: mqs){ 
System.out. SPIRE Ln Cad, toString()); 


Integer id = (Integer) arg; 
int index = id % mqs.size(); 
return mqs.get(index) ; 


} 
}, orderId); 
System.out.println(sendResult) ; 





消费 端 通 过 使 用 MessageListenerOrderly 类 来 解决 单 Message Queue 
的 消息 被 并 发 处 理 的 问题 ， 如 代码 清单 6-2 所 示 。 


代码 清单 6-2 MessageListenerOrderly 示 例 





consumer .registerMessageListener(new MessageListenerOrderly() { 
AtomicLong consumeTimes = new AtomicLong(0); 
@Override 
public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, 
ConsumeOrderlyContext context) { 
System.out.printf(" Received New Messages: " + new String(msgs.get(0).getBoc 
return ConsumeOrderlyStatus.SUCCESS; 


}); 





Consumer 使 用 MessageListenerOrderly 的 时 候 ， 下 面 四 个 Consumer 的 
设置 依旧 可 以 使 用 : setConsumeThreadMin、setConsumeThreadMax、 
setPull-BatchSize、setConsumeMessageBatchMaxSize。 前 两 个 参数 设置 
Consumer 的 线程 数 ，PullBatchSize 指 的 是 一 次 从 Broker 的 一 个 Message 
Queue 获 取消 息 的 最 大 数量 ， 默 认 值 是 32， 
ConsumeMessageBatchMaxSize 指 的 是 这 个 Consumer 的 Executor( 也 束 是 
调用 MessageListener 处 理 的 地 方 ) 一 次 传 入 的 消息 数 

(List<MessageExt>msgs 这 个 链表 的 最 大 长 度 ) ， 默 认 值 是 1。 


上 述 四 个 参数 可 以 使 用 ， 说 明 MessageListenerOrderly 并 不 是 简单 地 
禁止 并 发 处 理 。 在 MessageListenerOrderly 的 实现 中 ， 为 每 个 Consumer 
Queue 加 个 锁 ， 消 费 每 个 消 恩 前 ， 需 要 先 获得 这 个 消 恩 对 应 的 Consumer 
Queue 所 对 应 的 锁 ， 这 样 保证 了 同一 时 间 ， 同 一 个 Consumer Queue 的 消 
息 不 被 并 发 消费 ， 但 不 同 Consumer Queue 的 消息 可 以 并 发 处 理 。 














6.2 ”消息 重复 问题 


对 分 布 式 消 息 队 列 来 说 ， 同 时 做 到 确保 一 定投 递 和 不 重复 投递 是 很 
难 的 ， 也 就 是 所 谓 的 * 有 且 仅 有 一 次 ”。 在 鱼 和 能 掌 不 可 兼 得 的 情况 下 ， 
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消息 重复 一 般 情况 下 不 会 发 生 ， 但 是 如 果 消 息 量 大 ， 网 络 有 波动 ， 
消息 重复 就 是 个 大 概率 事件 。 比 如 Producer 有 个 函数 
setRetryTimesWhenSendFailed， 设 置 在 同步 方式 下 自动 重 试 的 次 数 ， 默 
认 值 是 32， 这 样 当 第 一 次 发 送 消 息 时 ，Broker 问 接收 到 了 消息 但 是 没有 
正确 返回 发 送 成 功 的 状态 ， 就 造成 了 消息 重复 。 


解决 消息 重复 有 两 种 方法 : 第 一 种 方法 是 保证 消费 逻辑 的 最 等 性 
(多 次 调用 和 一 次 调用 效果 相同 ); 男 一 种 方法 是 维护 一 个 已 消费 消 忆 
eee 消费 前 碍 询 这 个 消 轧 是 否 被 消费 过 。 这 两 种 方法 都 需要 使 用 者 

己 实现 。 























6.3 ”动态 增 减 机 器 


一 个 消息 队列 集群 由 多 台 机 器 组 成 ， 持 续 稳 定 地 提供 服务 ， 因 为 业 
务 需 求 或 硬件 故障 ， 经 常 需要 增加 或 减少 各 个 角色 的 机 器 ， 本 市 介绍 如 
何在 不 影响 服务 稳定 性 的 情况 下 动态 地 增 减 机 器 。 





6.3.1 动态 增 减 NameServer 


NameServer 是 RocketMQ 和 集群 的 协调 者 ， 集 群 的 各 个 组 件 是 通过 
NameServer 获 取 各 种 属性 和 地 址 信息 的 。 主 要 功能 包括 两 部 分 : 一 个 各 
个 Broker 定 期 上 报 自 己 的 状态 信息 到 NameServer; 另 一 个 是 各 个 客户 
端 ， 包 括 Producer、Consumer， 以 及 命令 行 工 具 ， 通 过 NameServer 获 取 
最 新 的 状态 信息 。 所 以 ， 在 启动 Broker、 和 生产 者 和 消费 者 之 前 ， 必 须 告 
诉 它 们 NameServer 的 地 址 ， 为 了 提高 可 靠 性 ， 建 议 启动 多 个 
NameServer. NameServer 占 用 资源 不 多 ， 可 以 和 Broker 部 署 在 同一 台 机 
器 。 有 多 个 NameServer 后 ， 减 少 某 个 NameServer 不 会 对 其 他 组 件 产 生 影 
啊 。 


有 四 种 种 方式 可 设置 NameServer 的 地 址 ， 下 面 按 优先 级 由 高 到 低 依 


次 介绍 : 


1) 通过 代码 设置 ， 比 如 在 Producer 中 ， 通 过 
Producer.setNamesrvAddr ("name-serverl-ip: port; name-server2-ip: 
port") 来 设置 。 在 mqadmin 命 令 行 工 具 中 ， 是 通过 -n name-server-ip1: 
port; name-server-ip2: port 参 数 来 设置 的 ， 如 果 自 定义 了 命令 行 工 具 ， 
也 可 以 通过 defaultMQAdminExt.setNamesrvAddr ("name-server1-ip: 
port; name-server2-ip: port") 来 设置 。 


2) 使 用 Java 启 动 参数 设置 ， 对 应 的 option 是 


rocketmq.namesrv.addr. 


3) 通过 Linux 坏 境 变 量 设置 ， 在 局 动 前 设置 变量 : 
NAMESRV_ADDR. 


4) 通过 HTTP 服 务 来 设置 ， 当 上 述 方 法 都 没有 使 用 ， 程 序 会 同一 个 
HTTP 地 址 发 送 请 求 来 获取 NameServer 地 址 ， 默 认 的 URL 
Je http://jmenv.tbsite.net:8080/rocketmq/nsaddr 〈 淘 宝 的 测试 地 址 ) ， 通 
itrocketmq.namesrv.domain# #OK 4 mijmenv.tbsite.net; 通过 
rocketmq.namesrv.domain.subgroup# BOK 7 minsaddr. 


第 4 种 方式 看 似 楷 琐 ， 但 它 是 唯一 文 持 动态 增加 NameServer， 无 须 
重启 其 他 组 件 的 方式 。 使 用 这 种 方式 后 其 他 组 件 会 每 隔 2 分 钟 请 求 一 次 





该 URL， 获 取 最 新 的 NameServer 地 址 。 





6.3.2 ”动态 增 减 Broker 


由 于 业务 增长 ， 需 要 对 集群 进行 扩容 的 时 候 ， 可 以 动态 增加 Broker 
角色 的 机 器 。 只 增加 Broker 不 会 对 原 有 的 Topic 产 生 影响 ， 原 来 创建 好 的 
Topic 中 数据 的 读 写 依然 在 原来 的 那些 Broker 上 进行 。 


集群 扩容 后 ， 一 是 可 以 把 新 建 的 Topic 指 定 到 新 的 Broker 机 器 上 ， 均 
衡 利 用 资源 ， 男 一 种 方式 是 通过 updateTopic 命 令 更 改 现 有 的 Topic 配 
置 ， 在 新 加 的 Broker 上 创建 新 的 队列 。 比 如 TestTopic 是 现 有 的 一 个 
Topic， 因 为 数据 量 增 大 需要 扩容 ， 新 增 的 一 个 Broker 机 器 地 址 是 
192.168.0.1: 10911， 这 个 时 候 执 行 下 面 的 命令 : sh./bin/mqadmin 
updateTopic-b 192.168.0.1: 10911-t TestTopic-n 192.168.0.100: 9876， 结 
果 是 在 新 增 的 Broker 机 器 上， 为 TestTopic 新 创建 了 8 个 读 写 队 列 。 


如 果 因 为 业务 变动 或 者 置换 机 器 需要 减少 Broker， 此 时 该 如 何 操作 
We? 减少 Broker 要 看 是 否 有 持续 运行 的 Producer， 当 一 个 Topic 只 有 一 个 
Master Broker， 停 挥 这 个 Broker 后 ， 消 息 的 发 送 肯 定 会 受到 影响 ， 需 要 
在 停止 这 个 Broker 前 ， 停 止 发 送 消息 。 


当 某 个 Topic 有 多 个 Master Broker， 停 了 其 中 一 个 ， 这 时 候 是 否 会 丢 
失 消息 呢 ? 答案 和 Producer 使 用 的 发 送 消 息 的 方式 有 关 ， 如 宁 使 用 同步 
方式 send (msg) 发 送 ， 在 DefaultMQProducer 内 部 有 个 自动 重 试 逻辑 ， 
其 中 一 个 Broker 停 了 ， 会 自动 问 男 一 个 Broker 发 消息 ， 不 会 发 生 于 消 忆 
现象 。 如 果 使 用 异步 方式 发 送 send (msg, callback) ， 或 者 用 
sendOneWay 方 式 ， 会 丢失 切换 过 程 中 的 消息 。 因 为 在 异步 和 
sendOneWay 这 两 种 发 送 方 式 下 ，Producer.setRetryTimesWhenSendFailed 
设置 不 起 作用 ， 发 送 失 败 不 会 重 试 。DefaultMQProducer 默 认 每 30 秒 到 
NameServer 请 求 最 新 的 路 由 消息 ，Producer 如 果 获 取 不 到 已 停止 的 
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如 果 Producer 程 序 能 够 暂停 ， 在 有 一 个 Master 和 一 个 Slave 的 情况 下 
也 可 以 顺利 切换 。 可 以 关闭 Producer 后 关闭 Master Broker， 这 个 时 候 所 
有 的 读 取 都 会 被 定 癌 到 Slave 机 器 ， 消 费 消 息 不 受 影响 。 把 Master Broker 
机 器 置换 完 后 ， 基 于 原来 的 数据 启动 这 个 Master Broker， 然 后 再 启动 
Producer 程 序 正 常 发 送 消 息 。 



































用 Linux 的 kill pid 命 令 就 可 以 正确 地 关闭 Broker，BrokerController 下 
有 个 shutdown 函 数 ， 这 个 函数 被 加 到 了 ShutdownHook 里 ， 当 用 Linux 的 
ki 命令 时 《〈 不 能 用 kill-9) ，shutdown 函 数 会 先 被 执行 。 也 可 以 通过 
RocketMQ 提 供 的 工具 (mqshutdown broker) 来 关闭 Broker， 它 们 的 原 
理 是 一 样 的 。 


6.4 各 种 故 隐 对 消息 的 影响 


我 们 期 望 消息 队列 集群 一 直 可 靠 稳 定 地 运行 ， 但 有 时 候 故障 是 难免 
的 ， 本 节 我 们 列 出 可 能 的 故障 情况 ， 看 看 如 何 处 理 : 


1) Broker 正 常 关 闭 ， 局 动 ; 


2) Broker 异 常 Crash， 然 后 启动 ; 








3) OS Crash， 重 启 ; 

4) 机 器 断 电 ， 但 能 马上 恢复 供电 ; 

5) 磁盘 损坏 ; 

6) CPU、 主板、 内存 等 关键 设备 损坏 。 


假设 现 有 的 RocketMQ 集 群 ， 每 个 Topic 都 配 有 多 Master 角 色 的 
Broker 供 写 入 ， 并 且 每 个 Master 都 至 少 有 一 个 Slave 机 器 (用 两 台 物 理 机 
就 可 以 实现 上 述 配 置 ) ， 我 们 来 看 看 在 上 述 情况 下 消息 的 可 靠 性 情况 。 


第 1 种 情况 属于 可 控 的 软件 问题 ， 内 存 中 的 数据 不 会 丢失 。 如 果 重 
启 过 程 中 有 持续 运行 的 Consumer，Master 机 器 出 故障 后 ，Consumer 会 自 
动 重 连 到 对 应 的 Slave 机 器 ， 不 会 有 消息 丢失 和 偏差 。 当 Master 角 色 的 机 
器 重启 以 后 ，Consumer 双 会 重新 连接 到 Master 机 器 (注意 在 启动 Master 
机 器 的 时 候 ， 如 果 Consumer 正 在 从 Slave 消 费 消 息 ， 不 要 停止 
Consumer。 假 如 此 时 先 停止 Consumer 后 再 启动 Master 机 器 ， 然 后 再 启动 
Consumer， 这 个 时 候 Consumer 束 会 去 读 Master 机 器 上 已 经 济 后 的 offset 
值 ， 造 成 消息 大 量 重 复 ) 。 


如 果 第 1 种 情况 出 现时 有 持续 运行 的 Producer， 一 台 Master 出 故障 
后 ，Producer 只 能 同 Topic 下 其 他 的 Master 机 器 发 送 消 恩 ， 如 朵 Producer 
采用 同步 发 送 方式 ， 不 会 有 消息 丢失 。 


第 2、3、4 种 情况 属于 软件 故障 ， 内 存 的 数据 可 能 丢失 ， 上 所 以 刷 稻 
策略 不 同 ， 造 成 的 影响 也 不 同 ， 如 果 Master、Slave 都 配置 成 




















SYNC_FLUSH， 可 以 达到 和 第 1 种 情况 相同 的 效果 。 

第 5、6 种 情况 属于 人 硬件 故障 ， 发 生 第 5、6 种 情况 的 故障 ， 原 有 机 器 
的 磁盘 数据 可 能 会 丢失 。 如 果 Master 和 Slave 机 器 间 配 置 成 同步 复制 方 
式 ， 某 一 台 机 器 发 生 5 或 6 的 故障 ， 也 可 以 达到 消息 不 丢失 的 效果 。 如 果 
Master 和 Slave 机 堪 间 是 异步 复制 ， 两 次 Sync 间 的 消息 会 丢失 。 

总 的 来 说 ， 当 设置 成 : 


1) 多 Master， 每 个 Master 带 有 Slave; 











2) 主 从 之 间 设 置 成 SYNC_MASTER:; 

3) Producer 用 同步 方式 写 ; 

A) 刷 盘 策略 设置 成 SYNC_FLUSH。 

就 可 以 消除 单 点 依赖 ， 即 使 某 台 机 器 出 现 极端 故障 也 不 会 丢 消 息 。 


6.5 WER 


有 些 场景 ， 需 要 应 用 程序 处 理 几 种 类 型 的 消息 ， 不 同 消息 的 优先 级 
不 同 。RocketMQ 是 个 先入 先 出 的 队列 ， 不 支持 消息 级 别 或 者 Topic 级 别 
的 优先 级 。 业 务 中 简单 的 优先 级 需求 ， 可 以 通过 间接 的 方式 解决 ， 下 面 
列举 三 种 优先 级 相关 需求 的 具体 处 理 方法 。 


第 一 种 是 比较 简单 的 情况 ， 如 果 当 前 Topic 里 有 多 种 相似 类 型 的 消 
息 ， 比 如 类 型 AA、AB、AC， 当 AB、AC 的 消息 量 很 大 ， 但 是 人 处理 速度 
比较 慢 的 时 候 ， 队 列 里 会 有 很 多 AB、AC 类 型 的 消息 在 等 候 处 理 ， 这 个 
时 候 如 果 有 少量 AA 类 型 的 消息 加 入 ， 就 会 排 在 AB、AC 类 型 消息 后 
面 ， 需 要 等 候 很 长 时 间 才 能 被 处 理 。 


如 果 业 务 需要 AA 类 型 的 消息 被 及 时 处 理 ， 可 以 把 这 三 种 相似 类 型 
的 消息 分 拆 到 两 个 Topic 里 ， 比 如 AA 类 型 的 消息 在 一 个 单独 的 Topic， 
AB、AC 类 型 的 消息 在 另外 一 个 Topic。 把 消息 分 到 两 个 Topic 中 以 后 ， 
应 用 程序 创建 两 个 Consumer， 分 别 订 阅 不 同 的 Topic， 这 样 消息 AA 在 单 
独 的 Topic 里 ， 不 会 因为 AB、AC 类 型 的 消息 太 多 而 被 长 时 间 延 时 处 理 。 


第 二 种 情况 和 第 一 种 情况 类 似 ， 但 是 不 用 创建 大 量 的 Topic。 举 个 
实际 应 用 场景 : 一 个 订单 处 理 系 统 ， 接 收 从 100 家 快递 门店 过 来 的 请 
求 ， 把 这 些 请 求 通过 Producer 写 入 RocketMQ; 订单 处 理 程序 通过 
Consumer 从 队列 里 读 取 消息 并 处 理 ， 每 天 最 多 处 理 1 万 单 。 如 果 这 100 个 
快递 门店 中 某 几 个 门店 订单 量 大 增 ， 比 如 门店 一 接 了 个 大 客户 ， 一 个 上 
午 就 友 出 2 万 单 消 晨 请 求 ， 这 样 其 他 的 99 家 门店 可 能 被 迫 等 待 门 店 一 的 2 
万 单 处 理 完 ， 也 就 是 两 天 后 订单 才能 被 人 处理， 显然 很 不 公平 。 


这 时 可 以 创建 一 个 Topic， 设 置 Topic 的 MessageQueue 数 量 超过 100 
个 ，Producer 根 据 订 单 的 门店 号 ， 把 每 个 门店 的 订单 写 入 一 个 
MessageQueue。DefaultMQPushConsumer 默 认 是 采用 循环 的 方式 逐个 读 
取 一 个 Topic 的 所 有 MessageQueue， 这 样 如 果 某 家 门店 订单 量 大 增 ， 这 
家 门店 对 应 的 MessageQueue 消 息 数 增多 ， 等 待 时 间 增 长 ， 但 不 会 造成 其 
他 家 门店 等 待 时 间 增 长 。 


DefaultMQPushConsumer 默 认 的 pullBatchSize 是 32， 也 就 是 每 次 从 
某 个 MessageQueue 读 取消 息 的 时 候 ， 最 多 可 以 读 32 个 。 在 上 面 的 场景 




















中 ， 为 了 更 加 公平 ， 可 以 把 pullBatchSize 设 置 成 1。 


第 三 种 情况 是 强 优先 级 需求 ， 上 两 种 情况 对 消息 的 “优先 级 ”要 求 不 
高 ， 更 像 一 个 保证 公平 处 理 的 机 制 ， 避 免 某 类 消息 的 增多 阻 加 其 他 类 型 
的 消息 。 现 在 有 一 个 应 用 程序 同时 处 理 TypeA、TypeB、TypeC 三 类 消 
息 。TypeA 处 于 第 一 优先 级 ， 要 确保 只 要 有 TypeA 消 息 ， 必 须 优先 处 
HE; TypeB 处 于 第 二 优先 级 ; TypeC 处 于 第 三 优先 级 。 对 这 种 要 求 ， 或 
者 逻辑 更 复杂 的 要 求 ， 就 要 用 户 目 己 编码 实现 优先 级 控制 ， 如 果 上 述 的 
三 类 消息 在 一 个 Topic 里 ， 可 以 使 用 PullConsumer， 自 主 控制 
MessageQueue 的 遍历 ， 以 及 消息 的 读 取 ;， 如 果 上 述 三 类 消息 在 三 个 
Topic 下 ， 逢 要 启动 三 个 Consumer， 实 现 逻 辑 控 制 三 个 Consumer 的 消 
sie 











6.6 本章 小 结 


本 章 根 据 使 用 场景 ， 讨 论 如 何 “ 可 靠 ” 地 收发 消息 。 即 在 要 求 消 居 顺 
厅 的 场景 下 ， 如 何 既 能 并 发 执行 ， 叉 能 保证 消 轧 顺序 ; 然后 分 析 在 可 能 
的 故障 场景 下 ， 如 何 应 对 以 保证 不 丢 消 息 、 不 中 断 服务 。RocketMQ 在 
设计 上 ， 有 重 试 机 制 来 保证 消息 不 丢 ， 造 成 的 结 末 是 可 能 存在 消 忆 重 
复 ， 这 一 点 需要 用 户 根据 具体 业务 场景 来 处 理 。 下 一 章 将 讨论 处 理 大 数 
据 量 消息 的 方法 。 








第 7 草 ”在 吐 量 优先 的 使 用 场景 


本 章 介绍 在 大 流量 场景 下 ， 提 高 RocketMQ 集 群 乔 吐 量 的 一 些 方 
法 ， 有 些 方法 当 服 务 器 出 异常 时 会 增 大 于 消息 的 概率 ， 用 户 需 要 根据 业 
务 需求 酌情 使 用 。 


7.1 在 Broker 冰 进行 消息 过 滤 


在 Broker 疹 进行 消 思 过滤， 可 以 减少 无 效 消息 发 送 到 Consumer， 人 少 
占用 网 络 带 宽 从 而 提高 吞吐 量 。Broker 端 有 三 种 方式 进行 消息 过 滤 。 





7.1.1 ” 消 恩 的 Tag 和 Key 


对 一 个 应 用 来 说 ， 尽 可 能 只 用 一 个 Topic， 不 同 的 消息 子 类 型 用 Tag 
来 标识 “每 条 消 轧 只 能 有 一 个 Tag) ， 服 务 嚣 端 基于 Tag 进 行 过 滤 ， 并 不 
需要 该 取消 息 体 的 内 容 ， 所 以 效率 很 局。 发送 消 息 设 置 了 Tag 以 后 ， 消 
费 方 在 订阅 消 恩 时 ， 才 可 以 利用 Tag 在 Broker 亲 做 消息 过 小 。 


其 次 是 消息 的 Key。 对 发 送 的 消息 设置 好 Key， 以 后 可 以 根据 这 个 
Key 来 查找 消息 。 所 以 这 个 Key 一 般 用 消息 在 业务 层面 的 唯一 标识 码 来 
表示 ， 这 样 后 续 查 询 消息 异常 ， 消 息 丢 失 等 都 很 方便 。Broker 会 创建 专 
门 的 索引 文件 ， 来 存储 Key 到 消息 的 映射 ， 由 于 是 哈 希 索引 ， 应 尽量 使 
Key 唯 一 ， 避 人 免 潜 在 的 哈 希 冲突 。 


Tag 和 Key 的 主要 差别 是 使 用 场景 不 同 ，Tag 用 在 Consumer 的 代码 











7.1.2 ”通过 Tag 进 行 过 滤 


用 Tag 方 式 进行 过 滤 的 方法 是 传 入 感 兴 趣 的 Tag 标 签 ，Tag 标 签 是 一 
个 普通 字符 串 ， 是 在 创建 Message 的 时 候 琴 加 的 ， 一 个 Message 只 能 有 一 
个 Tag。 使 用 Tag 方 式 过 滤 非 常 高 效 ，Broker 端 可 以 在 ConsumeQueue 中 
做 这 种 过 滤 ， 只 从 CommitLog 里 读 取 过 滤 后 被 命中 的 消息 。 看 一 下 
ConsumerQueue 的 存储 格式 ， 如 图 7-1 所 示 。 


- 8 Byte - 4 Byte - 8 Byte - 
| = 


| CommitLog Offset | Size Message Tag Hashcode 
图 7-1 ConsumerQueue 的 存储 格式 


Consume Queue 的 第 三 部 分 存储 的 是 Tag 对 应 的 hashcode， 是 一 个 定 
长 的 字符 串 ， 通 过 Tag 过 滤 的 过 程 就 是 对 比 定 长 的 hashcode。 经 过 
hashcode 对 比 ， 符 合 要 求 的 消息 补 从 CommitLog 恋 取出 来 ， 不 用 担心 
Hash 冲 突 问 题 ， 消 息 在 被 消费 前 ， 会 对 比 完整 的 Message Tag 字 符 串 ， 
消除 Hash 冲 突 造 成 的 误 读 。 




















7.1.3 FASQLAIA TUN A cE Ts 


使 用 Tag 方 式 过 滤 虽 然 高 效 ， 但 是 文 持 的 逻辑 比较 简单 ， 在 构造 
Message 的 时 候 ， 还 可 以 通过 putUserProperty 函 数 来 增加 多 个 自 定义 的 属 
性 ， 基 于 这 些 属性 可 以 做 复杂 的 过 小 逻辑 ， 如 代码 清单 7-1 所 示 。 


代码 清单 7-1 在 消息 中 增加 目 定 义 属 性 





Message msg = new Message("TopicTest", 

ag, 

("Hello RocketMQ " + i).getBytes(RemotingHelper .DEFAULT_CHARSET ) 
); . 
// Set some properties. 


msg.putUserProperty("a", String. valueOf(i)); 
msg.putUserProperty("b" “hello”); 





AUS FIR “SE MAD SD MRP J TEE a Alb, 我 们 用 类 似 SQL 表 
达 式 的 方式 对 消息 进行 过 滤 ， 用 法 如 下 “〈 目 前 只 文 持 在 PushConsumer 中 
实现 这 种 过 滤 ) : 








DefaultMQPushConsumer consumer = new DefaultMQPushConsumer ("please_rename_unique_grc 
consumer .registerMessageListener(new MessageListenerConcurrently() 
@Override public ConsumeConcurrentlyStatus consumeMessage 
(List<MessageExt> msgs, ConsumeConcurrentlyContext context) 
return ConsumeConcurrentlyStatus .CONSUME_SUCCESS; } }); consumer.start 








类 似 SQL 的 过 滤 表 达 式 ， 支 持 如 下 语法 : 

.数字 对 比 ， 比 如 >、>=、<、<=、BETWEEN、=; 
字符 串 对 比 ， 比 如 =、<>、IN; 

‘IS NULL or IS NOT NULL; 

4847S AND, OR, NOT. 

支持 的 数据 类 型 : 


.数字 型 ， 比 如 123、3.1415; 


.字符 型 ， 比 如 'abc、 注 意 必 须 用 单 引 号 ; 
:NULL， 这 个 特殊 字符 ; 
.布尔 型 ，TRUEorFALSE。 


SQL 表达 式 方 式 的 过 滤 需 要 Broker 先 读 出 消息 里 的 属性 内 容 ， 然 后 
做 SQL 计算 ， 增 大 磁盘 压力 ， 没 有 Tag 方 式 高 效 。 








7.1.4 Filter Server 方 式 过 滤 


Filter Server 是 一 种 比 SQL 表 达 式 更 灵活 的 过 滤 方 式 ， 人 允许 用 户 自 定 
义 Java 函 数 ， 根 据 Java 函 数 的 逻辑 对 消 明 进行 过 滤 。 


要 使 用 Filter Server， 首 先 要 在 局 动 Broker 前 在 配置 文件 里 加 上 
filterServer-Nums=3 这 样 的 配置 ， Broker 在 启动 的 时 候 ， 就 会 在 本 机 启动 
3 个 Filter Server 进 程 。Filter pele 类 似 一 个 RocketMQ 的 Consumer 进 程 ， 
它 从 本 机 Broker 获 取消 妃 ， 然 后 根据 用 户 上 传 过 来 的 Java 函 数 进 行 过 
滤 ， 过 滤 后 的 消息 再 传 给 远 端 的 Consumer。j 这 种 方式 会 占用 很 多 Broker 
机 堪 的 CPU 资源 ， 要 根据 实际 情况 说 BH. 上 传 的 java 人 但 记 要 经 过 i 
检查 ， 不 能 有 申请 大 内 存 、 创 建 线程 等 这 样 的 操作 ， 人 否则 容易 造成 
Broker 服 务 占 宕 机 。 实 现 过 小 逻辑 的 示例 如 代码 清 单 7-2 所 示 不 。 


代码 清单 7-2 ”实现 过 小 逻辑 的 代码 示例 











public class MessageFilterImpl implements MessageFilter { 
@Override 
public boolean match(MessageExt msg) { 
String property = msg.getUserProperty("Sequenceld"); 
if (property != null) { 
int id = Integer.parseInt(property) ; 
if ((id % 3) == © && (id > 10)) { 
return true; 
} 


} 
return false; 











上 面 代码 实现 了 过 滤 逻 辑 ， 它 是 根据 消息 的 ,Sequeneeld x 1 m iE 
来 过 滤 的 ， 其 实 不 一 定 要 根据 消息 属性 来 过 滤 ， 也 可 以 根据 消息 体 的 内 
容 或 其 他 特征 过 滤 ， 如 代码 清单 7-3 所 示 。 


代码 清单 7-3 ”使 用 FilterServer 的 Consumer 示 例 





public static void main(String[] args) throws InterruptedException, MQClientExceptic 
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer ("Consumer -GroupNamecc 
// 使 用 Java 代 码 ， 在 服务 器 做 消息 过 滤 
String filterCode = MixAll.file2String("/home/admin/MessageFilterImpl. java"); 
consumer .subscribe("TopicFilter7", "com.alibaba.rocketmq.example.filter.Mess 
consumer .registerMessageListener(new MessageListenerConcurrently() { 

















@Override 

public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, 
ConsumeConcurrentlyContext context) { 

System.out.println(Thread.currentThread().getName() + " Receive New Mess 
return ConsumeConcurrentlyStatus .CONSUME_SUCCESS; 


3); 
consumer.start(); 
System.out.println("Consumer Started."); 





在 使 用 Filter Server 的 Consumer 例 子 中 ， 主 要 是 把 实现 过 滤 逻 辑 的 类 
作为 参数 传 到 Broker 端 ，Broker 端 的 Filter Server 会 解析 这 个 类 ， 然 后 根 
据 match 函 数 里 的 逻辑 进行 过 滤 。 


7.2 ”提高 Consumer 处 理 能 力 


当 Consumer 的 处 理 速 度 跟 不 上 消息 的 产生 速度 ， 会 造成 越 来 越 多 的 
消息 积压 ， 这 个 时 候 首先 查看 消费 逻辑 本 身 有 没有 优化 空间 ， 除 此 之 外 
还 有 三 种 方法 可 以 提高 Consumer 的 处 理 能 力 。 


(1) 提高 消费 并 行 度 


在 同一 个 ConsumerGroup 下 〈Clustering 方 式 ) ， 可 以 通过 增加 
Consumer 实 例 的 数量 来 提高 并 行 度 ， 通 过 加 机 器 ， 或 者 在 已 有 机 器 中 局 
动 多 个 Consumer 进 程 都 可 以 增加 Consumer 实 例 数 。 注 意 总 的 Consumer 
数量 不 要 超过 Topic 下 Read Queue 数 量 ， 超 过 的 Consumer 实 例 接 收 不 到 
消息 。 此 外 ， 通 过 提高 单个 Consumer 实 例 中 的 并 行 处 理 的 线程 数 ， 可 以 
在 同一 个 Consumer 内 增加 并 行 度 来 提高 吞吐 量 〈 设 置 方法 是 修改 


consumeThreadMin 和 consumeThreadMax ) 。 
(2) 以 批量 方式 进行 消费 


某 些 业务 场景 下 ， 多 条 消息 同时 处 理 的 时 间 会 大 大 小 于 逐个 处 理 的 
时 间 总 和 ， 比 如 消费 消息 中 涉及 update 某 个 数据 库 ， 一 次 update10 条 的 
时 间 会 大 大 小 于 十 次 updatel 条 数据 的 时 间 。 这 时 可 以 通过 批量 方式 消费 
来 提高 消费 的 吞吐 量 。 实 现 方法 是 设置 Consumer 的 
consumeMessageBatchMaxSize 这 个 参数 ， 默 认 是 1， 如 果 设 置 为 N， 在 消 
居多 的 时 候 每 次 收 到 的 是 个 长 上 度 为 N 的 消 恩 链表 。 


(3) 检测 延 时 情况 ， 跳 过 非 重 要 消 忆 

Consumer 在 消费 的 过 程 中 ， 如 果 发 现 由 于 某 种 原因 发 生 严 重 的 消息 
堆积 ， 短 时 间 无 法 消除 堆积 ， 这 个 时 候 可 以 选择 丢弃 不 重要 的 消息 ， 使 
Consumer 尽 快 追 上 Producer 的 进度 ， 如 代码 清单 7-4 所 示 。 


代码 清单 7-4 判断 消息 堆积 并 处 理 示例 









































public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcur 
long Offset = msgs.get(0).getQueueOffset(); 

String maxOffset = msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET) ; long di 
if (diff > 90000) { 


return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; 








// 正 常 消费 消息 
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } 





如 代码 所 示 ， 当 东 个 队列 的 消息 数 堆 积 到 90000 条 以 上 ， 就 直接 丢 
弃 ， 以 便 快 速 退 上 发 送 消 息 的 进度 。 


7.3 ”Consumer 的 负载 均衡 


上 一 节 中 讲 到 ， 想 要 提高 Consumer 的 处 理 速度 ， 可 以 启动 多 个 
Consumer 并 发 处 理 ， 这 个 时 候 束 涉及 如 何在 多 个 Consumer 之 间 负 载 均 
衡 的 问题 ， 接 下 来 结合 源码 分 析 Consumer 的 负载 均衡 实现 。 


要 做 负载 均衡 ， 必 须知 道 一 些 全 局 信息 ， 也 就 是 一 个 
ConsumerGroup 里 到 底 有 多 少 个 Consumer， 知 道 了 全 局 信息 ， 才 可 以 根 
据 某 种 算法 来 分 配 ， 比 如 简单 地 平均 分 到 各 个 Consumer。 在 RocketMQ 
中 ， 负 载 均衡 或 者 消息 分 配 是 在 Consumer 端 代码 中 完成 的 ，Consumer 
0 信息 ， 然 后 自己 做 负载 均衡 ， 只 处 理 分 给 自己 的 那 
HB YH Ie 








7.3.1 DefaultMQPushConsumer 的 负载 均衡 


DefaultMQPushConsumer 的 负载 均衡 过 程 不 需要 使 用 者 操心 ， 客 户 
端 程序 会 自动 处 理 ， 每 个 DefaultMQPushConsumer 启 动 后 ， 会 马上 会 触 
发 一 个 doRebalance 动 作 ; 而 且 在 同一 个 ConsumerGroup 里 加 入 新 的 
DefaultMQPush-Consumer 时 ， 各 个 Consumer 都 会 被 触发 doRebalance 动 
作 。 





如 图 7-2 所 示 ， 上 有 具体 的 负载 均衡 算法 有 五 种 ， 默 认 用 的 是 第 一 种 
AllocateMessageQueueAveragely。 负 载 均衡 的 结果 与 Topic 的 Message 
Queue 数 量 ， 以 及 ConsumerGroup 里 的 Consumer 的 数量 有 关 。 负 载 均 衡 
的 分 配 粒度 只 到 Message Queue， 把 Topic 下 的 所 有 Message Queue 分 配 到 
不 同 的 Consumer 中 ， 所 以 Message Queue 和 Consumer 的 数量 关系 ， 或 者 
整除 关系 影响 负载 均衡 结果 。 


org.apache.rocketma.client 

admin 

common 

consumer 
listener 
rebalance 
© AllocateMessageQueueAveragely 
© AllocateMessageQueueAveragelyByCircle 
© AllocateMessageQueueByConfig 
© AllocateMessageQueueByMachineRoom 
© AllocateMessageQueueConsistentHash 


图 7-2 ”RocketMQ 客 户 端 负载 均衡 策略 


以 AllocateMessageQueueAveragely 策 略为 例 ， 如 果 创 建 Topic 的 时 
候 ， 把 Message Queue 数 设 为 3， 当 Consumer 数 量 为 2 的 时 候 ， 有 一 个 
Consumer 需 要 处 理 Topic 三 分 之 二 的 消息 ， 另 一 个 处 理 三 分 之 一 的 消 
息 ; 当 Consumer 数 量 为 4 的 时 候 ， 有 一 个 Consumer 无 法 收 到 消息 ， 其 他 








3 个 Consumer 各 处 理 Topic 三 分 之 一 的 消息 。 可 见 Message Queue 数 量 设 
置 过 小 不 利于 做 负载 均衡 ， 通 常情 况 下 ， 应 把 一 个 Topic 的 Message 
Queue 数 设置 为 16。 


7.3.2 DefaultMQPullConsumer 的 负载 均衡 


Pull Consumer 可 以 看 到 所 有 的 Message Queue， 而 且 从 哪个 Message 
Queue 读 取消 息 ， 读 消息 时 的 Offset 都 由 使 用 者 控制 ， 使 用 者 可 以 实现 任 
何 特殊 方式 的 负载 均衡 


DefaultMQPullConsumer 有 两 个 辅助 方法 可 以 帮助 实现 负载 均衡 ， 
一 个 是 registerMessageQueueListener 冰 数 ， 如 代码 清单 7-5 所 示 。 


代码 清单 7-5 registerMessageQueueL istener 





Consumer .registerMessageQueueListener("TOPICNAME", new MessageQueue-Listener() { 
public void MessageQueueChanged(String Topic, Set<MessageQueue> mgAll, Set<MessageQt 





re pister Mor sagr eee 函数 在 有 新 的 Consumer 加 入 或 退出 时 
被 触发 。 另 一 个 辅助 工具 是 MQPullConsumerScheduleService 类 ， 使 用 这 
个 Class 类 似 使 用 Default MOPushConsumer {Bee HEPA E 的 主动 性 
留 给 了 使 用 者 ， 如 代码 清单 7-6 所 示 。 


代码 清单 7-6 ”使 用 MQPullConsumerScheduleService 示 例 





public class PullConsumerServiceTest { 
public static void main(String[] args) throws MQClientException { 
final MQPullConsumerScheduleService scheduleService = new MQPull-ConsumerSct 
scheduleService.getDefaultMQPullConsumer().setNamesrvAddr("localh-ost:9876"° 
scheduleService.setMessageModel(MessageModel.CLUSTERING ); 
scheduleService.registerPullTaskCallback("testPullConsumer", new PullTaskCa] 
public void doPullTask(MessageQueue mq, PullTaskContext context) { 
MQPullConsumer Consumer = context.getPullConsumer(); 
try { 
long Offset = Consumer.fetchConsumeOffset(mq, false); 
if (Offset < 0) 
Offset = 0; 
PullResult pullResult = Consumer.pull(mg, "*", Offset, 32); 
System.out.printf("%s%n", Offset + "\t" + mq + "\t" + pullResult 
switch (pullResult.getPullStatus()) { 
case FOUND: 
break; 
case NO_MATCHED_MSG: 
break; 
case NO_NEW_MSG: 
case OFFSET_ILLEGAL: 
break; 
default: 
break; 


Consumer .updateConsumeOffset(mq, pullResult.getNextBeginOffset(° 
context.setPullNextDelayTimeMillis(1000) ; 

} catch (Exception e) { 
e.printStackTrace(); 


} 


/ 
scheduleService.start(); 





然后 我 们 看 一 看 在 MQPullConsumerScheduleService 类 的 实现 里 ， 实 
现 负 载 均衡 的 代码 ， 如 代码 清单 7-7 所 示 。 


代码 清单 7-7 MQPullConsumerScheduleService 的 负载 均衡 实现 





class MessageQueueListenerImpl implements MessageQueueListener { 
@Override 
public void MessageQueueChanged(String Topic, Set<MessageQueue> mqAll, Set<Messé 
MessageModel MessageModel = 
MQPullConsumerScheduleService. this .defaultMQPullConsumer .getMessageMode] 
switch (MessageModel) { 
case BROADCASTING: 
MQPul1lConsumerScheduleService.this.putTask(Topic, mqAll); 
break; 
case CLUSTERING : 
MQPul1lConsumerScheduleService.this.putTask(Topic, mqDivided) ; 
break; 
default: 
break; 





从 源码 中 可 以 看 出 ， 用 户 通 过 更 改 MessageQueueListenerImpl 的 实 
现 来 做 自己 的 负载 均衡 策略 。 


7.4 提高 Producer 的 发 送 速度 


发 送 一 条 消息 出 去 要 经 过 三 步 ， 一 是 客户 端 发 送 请 求 到 服务 器 ， 二 
是 服务 器 处 理 访 请求， 三 是 服务 器 向 客户 端 返回 应 答 ， 一 次 消息 的 发 送 
耗 时 是 上 述 三 个 步骤 的 总 和 。 在 一 些 对 速度 要 求 高 ， 但 是 可 靠 性 要 求 不 
高 的 场景 下 ， 比 如 日 志 收 集 类 应 用 ， 可 以 采用 Oneway 方 式 发 送 ， 
Oneway 方 式 只 发 送 请 求 不 等 待 应答， 即将 数据 写 入 客户 端的 Socket 绥 冲 
Pr Aa 
| 微 秒 级 。 


另 一 种 提高 发 送 速度 的 方法 是 增加 Producer 的 并 发 量 ， 使 用 多 个 
Producer 同 时 发 送 ， 我 们 不 用 担心 多 Producer 同 时 写 会 降低 消息 写 做 盘 
的 效率 ，RocketMQ 引 入 了 一 个 并 发 窗口 ， 在 窗口 内 消息 可 以 并 发 地 写 
入 DirectMem 中 ， 然 后 异步 地 将 连续 一 段 无 空洞 的 数据 刷 入 文件 系统 当 
中 。 顺 序 写 CommitLog 可 让 RocketMQ 无 论 在 HDD 还 是 SSD 磁 盘 情 况 下 
都 能 保持 较 高 的 写 入 性 能 。 目 前 在 阿里 内 部 经 过 调 优 的 服务 器 上 ， 写 入 
性 能 达到 90 万 + 的 TPS， 我 们 可 以 参考 这 个 数据 进行 系统 优化 。 


在 Linux 操 作 系 统 层级 进行 调 优 ， 推 荐 使 用 EXT4 文 件 系统 ，IO 调 度 
算法 使 用 deadline 算 法 。 


如 图 7-3 所 示 ，EXT4 创 建 /删除 文件 的 性 能 比 EXT3 及 其 他 文件 系统 
要 好 ，RocketMQ 的 CommitLog 会 有 频繁 的 创建 /删除 动作 。 























sec 


Bonnie++ create/delete 32K files 





16 000 120 
14 000 
100 
12 000 
80 
10 000 
8 000 60 
6 000 
40 
4 000 
20 
2 000 
o m 0 
EXT3 EXT4 XFS BTRFS 
W SEQ CREATE 国 SEQ DELETE E RND CREATE E RND DELETE 
= SEQ CREATE CUP% == SEQ DELETE CPU % RND CREATE CPU % RND DELETE CPU % 


图 7-3” 几 种 文件 系统 在 Bonnie++ 中 创建 /删除 32K 文 件 需要 的 时 间 


另外 ，IO 调 度 算 法 也 推荐 调整 为 deadline。deadline 算 法 大 致 思想 如 


TF: 实现 四 个 队列 ， 其 中 两 个 处 理 正 常 的 read 和 write 操作 ， 另 外 两 个 处 
理 超时 的 read 和 write 操作 。 正 常 的 read 和 write 队列 中 ， 元 素 按 扇 区 号 排 
E, HT 正常 的 IO 合并 处 理 以 提高 吞吐 量 。 因 为 IO 请 求 可 能 会 集中 在 某 
些 人 磁盘 位 置 ， 这 样 会 导致 新 来 的 请 求 一 直 被 合并 ， 可 能 会 有 其 他 倒 盘 位 
置 的 IO 请 求 被 狐 死 。 超 时 的 reaad 和 write 的 队列 中 ， 元 素 按 请 求 创建 时 间 
排序 ， 如 果 有 超时 的 请 求 出 现 ， 就 放 进 这 两 个 队列 ， 调 度 算 法 保证 超时 











(达到 最 终 期 限时 间 〉 的 队列 中 的 IO 请 求 会 优先 被 处 理 。 


7.5 系统 性 能 调 优 的 一 般 流程 


这 里 讨论 的 系统 是 指 能 完成 某 项 功能 的 软 便 件 整体 ， 比 如 我 们 用 
RocketMQ， 加 上 自己 写 的 Producer、Consumer 程 序 ， 部 署 到 一 台 服 务 器 
上 ， 组 成 一 个 消息 处 理 系统 。 本 节 介 绍 对 这 类 系统 进行 调 优 的 基本 流 
程 ， 供 读者 参考 。 


首先 是 搭建 测试 环境 ， 查 看 人 硬件 利用 率 。 把 测试 系统 搭建 好 以 后 ， 
要 想 办 法 模拟 实际 使 用 时 的 情况 ， 并 且 逐 步 增 大 请 求 量 ， 同 时 检测 系统 
的 TPS。 在 请 求 量 增 大 到 一 定 程度 时 ， 系 统 的 QPS 达 到 峰值 ， 这 个 时 候 
Fe eR een et ee marae 
用 情况 : 


(1) 使 用 TOP 命 令 查 看 CPU 和 内 存 的 利用 率 








Tasks: 109 total, 1 running, 108 sleeping, © stopped, © zombie 

%Cpu(S): 0.1 us, 0.2 sy, ©.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st 
KiB Mem : 8010440 total, 1556880 free, 1626048 used, 4827512 buff/cache 

KiB Swap: © total, © free, © used. 6058356 avail Mem 





上 面 的 数据 显示 ，CPU 有 99.8% 空 闪 ; 内 存 总 共 8G， 有 大 约 1.5G 空 
闲 。 


(2) 使 用 Linux 的 sar 命 令 查 看 网 卡 使 用 情况 





#sar -n DEV 2 10 

Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 
Average: etho 6.03 6.18 1.39 0.99 0.00 0.00 0.00 

Average: eth1 4.41 3.82 0.42 0.98 0.00 0.00 0.00 





‘FACE: LAN 接 口 ， 网 络 设备 的 名 称 。 
‘rxpck/s: 每 秒 钟 接收 的 数据 包 。 
txpck/s: 每 秒 钟 发 送 的 数据 包 。 
TXbyt/s: 每 秒 钟 接收 的 字 节 数 。 


txbyt/s: 每 秒 钟 发 送 的 字 市 数 。 

TXcmp/s: 每 秒 钟 接收 的 压缩 数据 包 。 
每 秒 钟 发 送 的 压缩 数据 包 。 

‘rxmest/s: 每 秒 钟 接收 的 多 播 数 据 包 。 


如 琳 想 进一步 验证 网 卡 是 否 达 到 了 极限 值 ， 可 以 使 用 iperf3 命 令 查 
。 还 可 以 用 netstat-t 查 看 网 卡 的 连接 情况 ， 看 是 否 有 大 量 连接 造成 堵 


‘txcmp/s: 

















ba 


然后 用 iostat 查 看 磁盘 的 使 用 情况 : 





#iostat -xdm 1 
Linux 3.10.0-514.6.1.e17.x86_64 (iZ2zehfpu32ir7r3v1lhhuwZ) 12/28/2017 
_x86_64_(4 CPU) 


Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-Sz avgqu-Ssz await r_av 
vda 0.00 1.04 0.01 1.15 0.00 0.01 19.84 0.00 2.45 
1 


x 0 . 
vdb 0.00 0.00 0.00 0.00 0.00 0.00 14.75 0.00 0.11 
0 0.00 





AAW EIN AOE, MARE ARS HR. LUE TE 
CPU、 网 卡 还 是 磁盘 ? FY USC ENRERE PA SHR 
ATM AS, IPRA WR REIS. EMU RST i RiT 
以 判断 是 发 送 的 数据 量 超出 了 网 卡 的 带宽 ， 可 以 考虑 更 换 高 速 网 卡 ， 或 
者 更 新 程序 减少 数据 发 送 量 。 


还 有 一 种 情况 是 这 三 者 都 没有 到 使 用 极限 ， 这 也 是 一 种 比较 常见 而 
且 有 优化 空间 的 情况 ， 这 种 情况 说 明 CPU 利 用 率 没 有 发 挥 出 来 ， 比 如 可 
能 是 锁 的 机 制 有 bug， 造 成 线程 阻塞 。 


对 于 Java 程 序 来 说 ， 接 下 来 可 以 用 Java 的 profiling 工 具 来 找 出 程序 的 
具体 问题 ， 比 如 jvisualvm、jstack、perfJ 等 。 


通过 上 面 这 些 工 具 ， 可 以 逐步 定位 出 是 哪些 Java 线 程 比较 慢 ， 哪 个 
函数 占用 的 时 间 多 ， 是 否 因为 存在 锁 造 成 了 忙 等 的 情况 ， 然 后 通过 不 断 
的 更 改 测 试 ， 找 到 影响 性 能 的 关键 代码 ， 最 终 解决 问题 。 








7.6 本章 小 结 


本 章 重 点 关注 性 能 ， 关 注 在 大 消息 量 的 情况 下 ， 如 何 提高 
RocketMQ 的 吞吐 量 。 首 先 介 绍 了 消息 过 滤 ， 在 服务 端 进行 消息 过 滤 可 
以 减少 无 效 消 息 传输 造成 的 带宽 浪费 。 Tag 是 最 常用 的 一 种 高 效 过 滤 方 
式 ， 此 外 还 可 以 用 SQL 表达 式 、FilterServer 来 过 滤 消 息 。 


另 一 个 提高 吞吐 量 的 方法 是 增加 集群 的 机 天 数 量 ， 提 高 并 及 性 ， 要 
根据 实际 场景 增加 Broker、Consumer 或 Producer 角 色 的 机 器 数量 。 





第 8 草 和 其 他 系统 交互 
8.1 在 SpringBoot 中 使 用 RocketMQ 


Spring Boot 因 为 方便 易 用 ， 在 Java 开 发 者 中 大 受 好 评 ， 被 誉 
为 “Spring 的 第 二 春 "”， 本 章 将 说 明 如 何在 Spring 项 目 中 快速 使 用 
RocketMQ. 


8.1.1 直接 使 用 


在 Spring Boot 项 目 中 ， 使 用 某 个 新 的 组 件 第 一 步 通常 是 加 入 这 个 组 
件 的 依赖 。 下 面 以 Maven 为 例 ， 说 明 如 何在 pom.xzml 中 加 入 RocketMQ 的 
依赖 ， 如 代码 清单 8-1 所 示 。 


代码 清单 8-1 Maven 方 式 的 RocketMQ 依 赖 








<dependency> 
<groupId>org.apache. rocketmq</groupId> 
<artifactId>rocketmq-client</artifactId> 
<version>4.2.0</version> 

</dependency> 





有 了 这 个 依赖 ， 就 可 以 在 Spring Boot 项 目 中 开发 RocketMQ 的 
Producer 和 Consumer 程 序 了 。 


使 用 RocketMQ 集 群 ， 有 很 多 参数 要 设置 ， 我 们 可 以 在 
application. properties 文 作 里 加 入 自己 命名 的 参数 ， 然 后 通过 @Value 注 解 
引入 。 几 个 重要 的 参数 是 : NameServer 的 地 址 、GoupName 名 称 和 Topic 
名 称 。 此 外 还 有 一 些 针 对 Producer 或 Consumer 的 参数 ， 可 以 写 到 
properties 文 件 里 ， 也 可 以 写 到 程序 里 。 


依赖 配置 都 做 好 以 后 ， 就 可 以 着 手 开发 Producer 和 Consumer 程 序 
了 。 我 们 可 以 把 发 送 消 息 和 消费 消息 的 功能 封装 成 Service， 供 其 他 代码 
引用 。Producer 和 Consumer 的 初始 化 比较 慢 ， 不 建议 每 发 一 个 消息 或 者 
消费 一 个 消息 就 启动 和 注销 对 应 的 Object， 所 以 适合 把 初始 化 操作 代码 
写 到 @PostConstruct 函 数 里 ， 把 关闭 操作 代码 写 到 @PreDestroy 函 数 里 。 
Spring Boot 项 目 中 的 Producer 程 序 示 例如 代码 清单 8-2 所 示 。 


代码 清单 8-2 Spring Boot 项 目 中 的 Producer 服 务 














@Service 
public class ProducerService { 
private DefaultMQProducer producer = null; 
@PostConstruct 
public void initMQProducer() { 
producer = new DefaultMQProducer (“producerGoupName” ) ; 
producer.setNamesrvAddr (metaqNameserver ); 
producer.setRetryTimeswhenSendFailed(3); 


try { 
producer.start(); 

} catch (MQClientException e) { 
e.printStackTrace(); 


public void send(String topic, String msg) { 
Message msg = new Message(topic, "", "", msg.getBytes()); 


try { 
producer .send(msg); 
return; 

} catch (Exception e) { 
e.printStackTrace(); 


return; 


} 
@PreDestroy 
public void shutDownProducer() { 
if (producer != null) { 
producer.shutdown(); 
} 


} 
} 





使 用 Consumer 的 方式 和 使 用 Producer 类 似 ， 但 是 具体 设置 会 因为 使 
用 的 具体 Class 不 同 而 不 同 。 调 用 Shutdown 函 数 是 必要 的 ， 否 则 可 能 因为 
程序 被 强制 关闭 而 丢 消息 。 


8.1.2 ”通过 Spring Messaging 方 式 使 用 


直接 使 用 的 方式 比较 简单 ， 也 足够 灵活 ， 但 不 是 很 “Spring Style”, 
Spring Boot 对 于 消息 传递 ， 有 统一 的 接口 模板 ， 基 于 这 个 模板 可 以 对 接 
各 种 类 型 的 消息 通信 组 件 ， 比 如 Kafka、RabbitMQ、RocketMQ 等 。 使 用 
这 种 方式 ， 其 基于 不 同 消息 队列 收发 消息 的 代码 类 似 ， 方 便 在 不 同 的 消 
县 队列 间 切 换 。 


具体 使 用 流程 分 为 三 个 步骤 : 添加 依赖 、 配 置 参数 和 引入 模板 。 添 
加 RocketMQ 插 件 示 例 ， 如 代码 清单 8-3 所 示 。 


代码 清单 8-3 Spring Boot 的 RocketMQ 插 件 











<!-- 在 pom.xml 中 添加 依赖 - -> 

<dependency> 
<groupId>org.apache.rocketmq</groupId> 
<artifactId>spring-boot-starter-rocketmq</artifactId> 
<version>1.0.0-SNAPSHOT</version> 

</dependency> 











如 果 mvn 找 不 到 这 个 依赖 ， 可 以 在 GitHub 上 下 载 源 码 ， 本 地 构建 。 
然后 是 在 properties 文 件 中 加 入 配置 选项 ， 如 代码 清单 8-4 所 示 。 
代码 清单 8-4 Spring Boot 的 RocketMQ 相 关 配 置 选项 





## application.properties 

spring. rocketmq.name-server=127.0.0.1:9876 
spring.rocketmq. producer. group=my-group 
spring.rocketmq.producer.retry-times-when-send-async-failed=0 

spring. rocketmq.producer.send-msg-timeout=300000 
spring.rocketmq.producer.compress-msg- body -over -howmuch=4096 
spring.rocketmq. producer .max-message -Size=4194304 
spring.rocketmq.producer.retry-another -broker -when-not-store-ok=false 
spring.rocketmq.producer.retry-times-when-send-failed=2 





更 多 的 配置 选项 ， 可 以 到 源码 中 查找 。 由 于 Spring Boot 项 目 和 
RocketMQ 项 目 变 化 很 快 ， 具 体 如 何以 Spring Messaging 的 方式 发 送 和 接 
收 消息 ， 大 家 可 以 自行 搜索 相关 的 示例 和 说 明 。 最 新 的 文档 可 以 参考 
Spring Boot 文 档 的 Messaging 部 分 ， 以 及 GitHub 中 的 rocketmq-externals 项 


8.2 直接 使 用 云 上 RocketMQ 


阿里 云 的 很 多 产品 都 是 来 自 于 集团 内 部 开发 的 优秀 中 间 件 ， 
RocketMQ 就 是 其 中 之 一 ， 阿 里 云 的 MQ 产 品 就 是 基于 RocketMQ 实 现 
的 ， 后 台 技 术 团队 同样 是 开发 RocketMQ 的 团队 。 


现在 产品 迭代 的 节奏 越 来 越 快 ， 尤 其 对 于 中 小 型 公司 来 说 ， 直 接 使 
用 云 产 品 可 以 省 去 部 署 、 运 维 的 繁琐 工作 ， 加 快 自 身 核 ， 
度 。 当 业务 量 上 升 到 一 定 规模 ， 业 务 形态 基本 稳定 后 ， 再 自己 部 署 、 
维 或 二 次 开发 独立 的 中 间 件 产品 。 

如 果 仔 细 阅 读 了 前 面 的 章节 ， 参 考 阿 里 云 MQ 的 说 明文 档 进 行 开 发 
= 常 容易 了 ， 比 如 阿里 云 MQ 文 档 中 的 发 送 消 息 Demo， 如 代码 清单 8- 
OAT ZN o 


代码 清单 8-5 阿里 云 MQ 产 品 发 送 消息 示例 
































public class ProducerTest { 
public static void main(String[] args) { 
Properties properties = new Properties(); 
// 您 在 MQ 控制 台 创建 的 Producer ID 
properties. put (PropertyKeyConst. ProducerId, "XXX"); 
/ 鉴 权 用 AccessKey， 在 阿里 云 服务 器 管理 控制 台 创建 
properties.put(PropertyKeyConst.AccessKey, "XXX"); 
// 鉴 权 用 SecretKey, 在 阿里 云 服务 器 管理 控制 台 创建 
properties.put(PropertyKeyConst.SecretKey, "XXX"); 
// 设置 TCP 接 入 域名 (此 处 以 公共 云 的 公 网 接 入 为 例 ) 
properties.put(PropertyKeyConst.ONSAddr, 
"http://onsaddr-internet.aliyun.com/rocketmq/nsaddr4client-internet"); 
Producer a = ONSFactory. oe pea ee 
// 在 发 送 消息 前 ， 必 须 调用 start 方法 来 启动 Producer， 只 需 调 用 一 次 即 可 
producer.start(); 
// 循 环 发 送 消 息 
while(true) { 
Message msg = new Message( // 
// 在 控制 台 创建 的 Topic， 即 该 消息 所 属 的 Topic 名 称 
"TopicTestMQ", 
// Message Tag, 
// 可 理解 为 Gmail 中 的 标签 ， 对 消息 进行 再 归 类 ， 方便 Consumer 指定 
过 滤 条 件 在 MQ 服务 器 过 滤 

















































































































































































































dy 
// 任何 二 进 制 形式 的 数据 ， MQ 不 做 任何 干预 ， 
// 需要 Producer 与 Consumer 协商 好 一 致 的 序列 化 和 反 序 列 化 方式 
"Hello MQ".getBytes()); 
// 设置 代表 消息 的 业务 关键 属性 ， 请 尽 可 能 全 局 唯一 ， 以 方便 您 在 无 法 正常 收 到 
消息 情况 下 ， 可 通过 MQ 控制 台 查 询 消息 并 补 发 
// YER: 不 设置 也 不 会 影响 消息 正常 收发 
msg.setKey("ORDERID_100"); 































































































// 发 送 消息 ， 只 要 不 抛 异常 就 是 成 功 

// 打印 Message ID, 以 便 用 于 消息 发 送 状态 查询 

SendResult sendResult = producer.send(msg); 

System.out.println("Send Message success. Message ID is: " + sendResult. 


} 

// 在 应 用 退出 前 ， 可 以 销毁 Producer 对 象 
// 注意 : 如 果 不 销毁 也 没有 问题 

producer .Shutdown( ) ， 
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这 个 示例 程序 和 之 前 介绍 的 Producer 程 序 比 起 来 ， 只 是 把 设置 
GroupName、NameServer 地 址 的 部 分 ， 换 成 了 阿里 云 账 号 的 Key，Secret 
和 相应 域名 ， 其 他 部 分 非常 相似 。 详细 信息 和 最 新 的 文档 请 参 考 阿里 云 
MQ 产品 页 面 (https://cn.aliyun.com/product/ons ) 
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图 8-1 阿里 去 RocketMO 产 品 页 面 


8.3 ”RocketMQ 与 Spark、Flink 对 接 


Spark 和 Flink 都 有 对 流 式 计算 的 文 持 ， 如 果 不 考 虑 并 发 性 的 话 ， 可 
以 在 自己 的 程序 中 启动 RocketMQ 的 Consumer 或 Producer， 人 负责 从 
RocketMQ 集 群 获取 或 发 送 消息 ， 同 时 再 启动 Spark 或 Flink 的 Client 程 
序 ， 负 责 和 Spark 或 Flink 交 互 。 


如 果 需 要 利用 Spark、Flink 本 喘 的 并 发 处 理 ， 需 要 实现 相应 的 
Connector，RocketMQ 和 Spark 的 Connector 有 了 实现 ， 代 码 
在 https://github.com/apache/rocketmq-externals/tree/master/rocketmq-spark 
。RocketMQ 和 Flink 的 Connector 当 前 正在 开发 中 ， 有 兴趣 的 也 可 以 参与 
贡献 代码 。 


8.4” 自 定义 开发 运 维 工具 


生产 环境 的 RocketMQ 集 群 ， 需 要 持续 运行 并 且 要 有 较 局 的 稳定 
人 性 ， 运 维 是 件 重 要 但 有 时 候 很 紧 琐 的 事 ， 本 六 介绍 运 维 工 具 的 相 头头 


合 。 











S 


8.4.1 开源 版 本 运 维 工具 功能 介绍 


第 1 章 介绍 过 如 何 启动 运 维 页 面 ， 运 维 页面 打 开 后 ， 从 左 至 右 有 7 个 
Tab， 分 别 是 : 配置 、 轨 驶 舱 、 集 群 信 息 、Topic 信 息 、Consumer 信 息 、 
Producer 信 息 和 消息 查询 ， 如 图 8-2 所 示 。 
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日 期 : 2018-03-08 


Broker TOP 10 GB Totaldsg Broker 5min trend 
2500.00 


2000.00 








0.00 + T T T T 
10:16:00 10:26:00 10:54:00 10:42:00 10:50:00 10:56:00 11 





主题 | broker-106 


Topic TOP 10 Topic 5min trend 





图 8-2 ”RocketMQ 控 制 台 


首先 在 配置 页 面 ， 设 置 好 NaveServer 的 地 址 。 修 改 这 个 服务 是 否 使 
用 VIPChannel， 取 诀 于 你 的 RocketMQ 版 本 ， 如 果 版 本 小 于 3.5.8， 请 设 
置 不 使 用 ， 否 则 保持 默认 值 (VIPChannel 用 于 实现 读 写 分 离 ， 是 3.5.8 以 
后 的 版 本 才 增 加 的 功能 


在 区 驶 舱 中 可 以 查看 Broker 的 消息 量 〈 总 量 /5 分 钟 图 ) ， 还 可 以 碍 
看 单一 主题 的 消息 量 〈 总 量 / 趋 势 图 ) 。 


在 集群 信息 页 面 ， 可 以 查看 集群 数量 、 地 址 、 主 从 的 分 布 情况 ， 还 
可 以 查看 Broker 的 运行 状态 信息 和 配置 信息 。 


Topic 页 面 展 示 所 有 的 主题 ， 可 以 通过 搜索 框 进行 过 小 ， 肾 选 普通 / 
重 试 / 死 信 类 型 的 主题 ， 还 可 以 添加 /更 新 主题 ， 修 改 主题 的 配置 参数 。 











每 个 参数 的 含义 和 MQAdmin 命 令 中 updateTopc 命 令 的 参数 对 应 。 还 可 以 
查看 每 个 主题 的 消息 投递 状态 ， 消 息 的 路 由 信息 《〈 这 个 主题 的 消息 会 发 
往 哪 些 Broker， 对 应 Broker 的 Message Queue 信 息 ) 。 还 可 以 癌 某 个 主题 
发 送 测试 消息 和 重 置 消费 位 点 (Offset)。 


Consumer 信 息 页 面 展示 所 有 的 消费 组 ， 还 可 以 通过 搜索 框 进行 搜 
索 ， 手 动 刷新 页 面 或 每 隔 五 秒 定时 刷新 页 面 ， 按 照 订 阅 组 /数量 /TPS/ 延 
述 进行 排序 ， 添 加 /更 新 消费 组 等 。 


Producer 信 息 页 面 ， 可 以 通过 Topic 和 Group 查询 在 线 的 消息 生产 者 
信息 ， 信 息 包含 客户 端的 主机 、 版 本 等 。 


消息 查询 页 面 ， 可 以 根据 Topic 的 时 间 、Key 和 消息 ID 进行 消息 碍 
询 。 消 妃 详 情 可 以 展示 这 条 消息 的 详细 内 容 。 消 妃 详 情 可 以 碍 看 消 妃 对 
应 的 具体 消费 组 的 消费 情况 《如 果 弄 常 ， 可 以 碍 看 具体 的 寞 党 信息 ) 。 
可 以 加 指定 的 消费 组 重 发 消息 。 














8.4.2 ”基于 Tools 模 块 开 发 目 定 义 运 维 工 具 


RocketMQ-Console 是 一 个 基于 Spring Boot 开 发 的 运 维 页 面 工具 ， 我 
们 可 以 参考 它 的 源码 进行 和 目 定义 功能 的 运 维 工具 开发。 


RocketMQ 源 码 中 有 一 个 Tools 模 块 ， MQAdmin 相 关 合 命令 的 实现 就 在 
这 里 ， 如 果 我 们 熟悉 了 MQAdmin 命 令 的 功能 ， 就 很 容易 找到 实现 某 个 
功能 的 源码 。RocketMQ 的 Tools 模 块 如 图 8- 3 所 示 。 


Tools 虱 决 尖 碍 中 有 一 | command 包 ， 里 面 列 出 了 各 个 组 件 相 关 的 
命令 ， 如 果 想 实现 目 定 义 的 运 维 功能 ， 可 以 直接 从 这 里 查找 并 参考 它 的 
源码 。 RocketMQ 是 使 用 Java 语 言 开发 的 ， 比 起 Kafka 的 Scala 语 言 和 
RabbitMQ 的 Erlang 语 襄 言 ， 更 容易 找到 技术 人 员 进 行 定 制 开发 。 大 规模 使 
用 后 ， 过 到 “疑难 杂 症 ”也 可 以 直接 查看 源码 ， 找 到 深层 次 的 原因 。 
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图 8-3 ”RocketMQ 的 Tools 模 块 


8.5 ”本章 小 结 


作为 一 个 中 间 件 产品 ， 会 比 普通 软件 更 多 地 需要 和 其 他 系统 打 交 
道 ， 本 章 介 绍 了 如 何 与 SpringBoot、Spark、Flink 等 软件 进行 交互 。 同 时 
介绍 了 使 用 云端 的 RocketMQ 产 品 ， 以 及 上 自 定义 开发 运 维 工具 的 方法 。 
T 我 们 将 更 深入 地 介绍 RocketMQ， 从 源码 层面 进行 分 











第 9 章 ” 首 个 Apache 中 间 件 顶级 项 目 


本 书 第 1 一 8 章 重 点 介绍 的 是 如 何 用 好 RocketMQ， 而 从 本 音 开 始 到 
本 书 结尾 的 这 些 章节 ， 重 点 介绍 RocketMQ 的 源码 。 作 为 一 个 中 间 件 产 
品 ， 想 真正 用 好 ， 甚 全 用 来 为 目 己 的 业务 做 定制 化 开发 ， 必 须 深入 了 解 
源码 才 行 。 本 章 介 绍 RocketMQ 项 目的 概况 。 





9.1 RocketMQ 的 前 世 今 生 


阿里 巴巴 消息 中 间 件 起 源 于 2001 年 的 五 彩 石 项 目 ，Notify 在 这 期 间 
应 运 而 生 ， 用 于 交易 核心 消息 的 流转 。 


2010 年 ，B2B 开 始 大 规模 使 用 ActiveMQ 作 为 消息 内 核 ， 随 着 阿里 业 
务 的 快速 发 展 ， 急 需 一 款 支 持 顺序 消息 ， 拥 有 海量 消息 堆积 能 力 的 消息 
中 间 件 ，MetaQ 1.0 在 2011 年 诞生 。 


2012 年 ，MetaQ 已 经 发 展 到 了 3.0 版 本 ， 并 抽象 出 了 通用 的 消息 引擎 
RocketMQ。 随 后 ， 对 RocketMQ 进 行 了 开源 ， 阿 里 的 消息 中 间 件 正式 走 
入 了 公众 视野 。 


2015 年 ，RocketMQ 已 经 经 历 了 多 年 双 十 一 的 洗礼 ， 在 可 用 性 、 可 
靠 性 以 及 稳定 性 等 方面 都 有 出 色 的 表现 。 与 此 同时 ， 云 计算 大 行 其 道 ， 
阿里 消息 中 间 件 基于 RocketMQ 推 出 了 Aliware MQ 1.0， 开 始 为 阿里 云 上 
成 千 上 万 家 企业 提供 消息 服务 。 


2016 年 ，MetaQ 在 双 十 一 期 间 承 载 了 万 亿 级 消息 的 流转 ， 跨 越 了 一 
个 新 的 里 程 碑 ， 同 时 RocketMQ 进 入 Apache 凡 化 。 
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图 9-1 Re eal 


9.2 ”Apache 顶级 项 目 (TLP) 之 路 


RocketMQ 的 开源 模式 不 是 传统 意义 上 的 开放 内 核 模式 ， 而 是 和 
Apache Hadoop、OpenStack 这 一 类 开源 平台 模式 类 似 ， 和 尝试 把 开源 世界 
和 专 有 世界 完美 地 结合 起 来 ， 在 真正 的 协作 平台 上 生产 专 有 产品 。 未 来 
希望 像 Redhat、CentOS 或 Fedora 这 些 产 品 那 样 ， 把 产品 簇 的 协同 发 展 效 
应 体现 在 RocketMQ 的 演进 中 。 


在 Apache 社 区 ， 一 个 很 重要 的 理念 是 Community over Code， 社 区 
是 判断 一 个 孵化 项 目 能 否 毕业 的 重要 考核 标准 ， 有 点 像 我 们 常 说 的 “ 客 
户 第 一 ”。 除 了 社区 ， 优 秀 的 代码 是 必要 条 件 ， 代 码 质 量 不 过 硬 根本 不 
会 有 一 个 健康 多 元 的 社区 ， 注 重 代码 的 同时 还 要 重视 社区 、 设 计 、 产 品 
带 给 用 户 的 体验 。 


RocketMQ 在 进入 Apache 之 前 ， 已 经 开源 了 3 年 时 间 。 历 经 多 次 双 十 
一 洗礼 ，Rocket MQ 在 国内 积累 了 一 定 的 口碑 ， 社 区 也 有 不 错 的 Active 
Contributors， 但 这 些 还 远 远 不 够 。 在 准备 申请 进入 Apache 之 前 ， 团 队 甚 
至 包括 社区 对 RocketMQ 做 了 大 量 重 塑 工作 。 如 国际 化 方面 ， 在 GitHub 
上 利用 sidebar 特 性 重新 设计 编排 了 文档 ， 如 今 已 加 入 了 User Guide, 
Quick Start. Architecture & Design. How to contribute. Community, 
FAQ 这 些 产品 标 配 的 文档 结构 。 代 码 层 面 也 进行 了 很 多 优化 ， 如 去 除 
GBK 字 符 ， 全 面 拥抱 UTF-8， 重 写 API JavaDoc; 还 有 清理 代码 ， 优 化 代 
人 码 结 构 ; 利用 JDepend 优 化 组 件 之 间 的 抽象 依赖 关系 ， 利 用 Findbugs 扫 
描 代 码 漏 润 ， 指 导 规 范 编码 等 。 交 付 方面 ， 规 范 Release 流 程 ， 使 用 按 
New Features、Improvement 和 Bug 分 类 的 Release note。 社 区 层面 则 开局 
了 全 瑞 式 互动 ， 发 布 提问 题 的 技巧 。 


经 过 这 些 准 备 ，RocketMQ 完 成 了 从 3.0 到 4.0 的 悄然 升级 。 而 4.0 是 个 
过 渡 版 本 (和 3.0 相 比 ， 架 构 层 面 没有 较 大 的 改变 ) ， 也 是 在 Apache 开 
启 孵 化 的 版 本 。 通 过 孵化 ， 像 精细 设计 、 代 码 Review、 编 码 规 约 、 分 支 
模型 、 发 布 规约 等 软件 研发 流程 被 重视 起 来 ， 无 规矩 不 成 方圆 ， 这 对 一 
个 全 球 协作 的 开源 项 来 说 尤为 重要 。 














9.3 ”源码 结构 


RocketMQ 的 源码 结构 如 图 9-2 所 示 ， 整 个 项 目 是 用 Maven 来 管理 
的 ， 共 有 十 几 个 模块 ， 主 要 功能 通过 broker、client、common、 
namesrv、remoting、store、tools 这 几 个 模块 实现 。 


namesrv、broker、client 这 三 个 模块 前 文 都 有 介绍 ，namesrv 是 分 布 
式 队 列 集 群 的 协调 者 ，broker 实 现 了 消息 队列 的 主体 ，client 包 括 生产 者 
和 消费 者 ， 包 括 使 用 消息 队列 的 很 多 辅助 方式 。common 模 块 包括 一 些 
公共 的 功能 类 实现 ，remoting 是 通信 相关 功能 的 实现 ，store 是 消息 存储 
的 实现 ，tools 主 要 是 管理 工具 ， 用 来 管理 集群 。 


te .idea 
Ws broker [rocketmq-broker] 
i client [rocketmq-client] 
B= common [rocketmq-common] 
Ml dev 
B distribution [rocketmq-distribution] 
B= example [rocketmq-example] 
is filter [rocketma-filter] 
is filtersrv [rocketmq-filtersrv] 
B logappender [rocketmq-logappender] 
B= namesrv [rocketmq-namesrv] 
B= openmessaging [rocketmq-openmessaging] 
B= remoting [rocketmq-remoting] 
B srvutil [rocketmq-srvutil] 
B= store [rocketmq-store] 
tw style 
B test [rocketmq-test] 
B= tools [rocketmq-tools] 
图 9-2 ”RocketMQ 源 码 结构 


9.4 AWA NES 


RocketMQ 的 源码 在 GitHub 上 一 直 不 断 更 新 ， 从 GitHub 上 可 以 下 载 
到 最 新 的 代码 。RocketMQ 在 GitHub 上 的 地 址 
是 https://github.com/apache/rocketmq ，GitHub 上 的 代码 结构 是 未 发 布 版 
的 〈 见 图 9-3) 。 


除了 RocketMQ 主 体 项 目 ， 还 有 很 多 和 RocketMQ 紧 密 相关 的 功能 ， 
比如 管理 控制 台 ， 以 及 和 Redis、Spark、Flink 对 接 的 插件 等 ， 这 些 代码 
被 放 到 一 个 单独 的 GitHub 库 中 ， 地 址 


是 https://github.com/apache/rocketmq-externals 。 


W github 
W broker 

i client 

Es common 

im dev 

本 distribution 
im example 

Ea filter 

i filtersrv 

im logappender 
lm namesrv 

Ea openmessaging 
Es remoting 

Ea srvutil 

im store 

lm style 

im test 

i tools 

目 .gitignore 

B .travis.yml 
E BUILDING 


目 CONTRIBUTING.md 


El LICENSE 
目 NOTICE 
E README.md 


目 pom.xml 


Add a modified version of ISSUE TEMPLATE that created by the bookkeep._. 
[maven-release-plugin] prepare release rocketmq-all-4.2.0 
[maven-release-plugin] prepare release rocketmq-all-4.2.0 
(HOTFIX][ROCKETMQ-356] Change MQVersion to 4.2.0 

[ROCKETMQ-302] TLP clean up, removes incubating related info from cod... 
[maven-release-plugin] prepare release rocketma-all-4.2.0 
{maven-release-plugin] prepare release rocketmq-all-4.2.0 
{maven-release-plugin] prepare release rocketma-all-4.2.0 
(maven-release-plugin] prepare release rocketma-all-4.2.0 
[maven-release-plugin] prepare release rocketma-all-4.2.0 
{maven-release-plugin] prepare release rocketmq-all-4.2.0 
[maven-release-plugin] prepare release rocketmq-all-4.2.0 

[HOTFIX] Update the out of date test certificates 

[maven-release-plugin] prepare release rocketmq-all-4.2.0 
[maven-release-plugin] prepare release rocketma-all-4.2.0 

Polish 

{maven-release-plugin] prepare release rocketmq-all-4.2.0 
[maven-release-plugin] prepare release rocketma-all-4.2.0 

Aggregate packaging specific files to a new sub-module: distribution 
[ROCKETMQ-302] TLP clean up, removes incubating related info from cod... 
[ROCKETMQ-168] Polish the BUILDING guide. 

[ROCKETMQ-302] TLP clean up, removes incubating related info from cod... 
[ROCKETMQ-87] Add separate LICENSE and NOTICE files for binary releas... 
[ROCKETMQ-302] TLP clean up, removes incubating related info from cod... 
Polish the readme with Github issue link 


[HOTFIX] Move pull request template to .github 


图 9-3 ”RocketMQ 在 GitHub 上 的 代码 结构 


如 有 果 打 算 页 献 代 码 ， 官 网 的 指南 页 面 是 必 读 的 ， 地 址 
是 http://rocketmq.apache.org/docs/how-to-contribute/ ， 根 据 文档 说 明 的 步 
又 ， 提 交 PR 即 可 。 如 果 不 贡 献 代 码 ， 也 可 以 查看 某 个 功能 的 PR， 看 看 
大 家 的 讨论 和 设计 思路 ， 对 理解 源码 也 有 帮助 。 


Ba dev [ROCKETMQ-236] Script to merge github pull request 


Bs rocketmq-console update console's readme closes apache/rocketmq-externals#8 

Ba rocketmq-cpp [ROCKETMQ-352] Import the donation code from Qiwei Wang 

Ba rocketmq-docker [ROCKETMQ-183] Play Script to run broker and namesrv at local in dock... 
Ba rocketma-flink Create directory for beam, flink,spark,storm,mysql,redis, mongodb 

i rocketmq-flume Flume update to 1.8.0. (#44) 

im rocketmq-go Go-Client remoting and RocketMgqClient common method implement, closes a... 
Ea rocketmq-jms Migrate rocketmq-jms to here. 

Es rocketmq-mysal Prepare release mysql replicator 1.1.0 version 

Es rocketmq-php [ROCKETMQ-171] initialized the PHP_SDK basic structure closes apache/... 
Es rocketmq-redis 1. Add more event to downstream to rocketmg .eg(PreFullSync and PostF... 
E rocketmq-spark bugfix: fixup wrong offset storing in interval timer 

E rocketmq-spring-boot-starter Rename the dir of spring boot starter 

B .gitignore support windows platform for rocketmaq-cpp code 

travis.yml travis ci 

E README.md Add two chapters rocketmq-cpp and contribute in README 


图 9-4 rocket-externals{t i444 #4 


95 本章 小 结 


RocketMQ 是 阿里 最 优秀 的 中 间 件 之 一 ， 本 章 介 绍 了 RocketMQ 的 历 
史 ， 以 及 其 目前 作为 Apache 顶 级 项 目的 现状 。 下 一 章 将 从 NameServer 入 
手 开 始 分 析 源 码 。 





第 10 章 ”NameServer 源 人 码 解 析 


第 4 章 介绍 过 NameServer 的 主要 功能 ， 功 能 不 多 但 是 很 重要 ， 本 章 
分 析 NameServer 的 源码 ， 让 读者 对 NameServer 有 更 进一步 的 了 解 。 





10.1 模块 入 口 代码 的 功能 


本 节 介 绍 入 口 代 人 码 的 功能 ， 阅 读 源码 的 时 候 ， 很 多 人 喜欢 根据 执行 
逻辑 ， 先 从 入 口 代码 看 起 。NameServer 部 分 入 口 代 码 主要 完成 命令 行 参 
数 解析 ， 初 始 化 Controller 的 功能 。 





10.1.1 ”入口 函数 


首先 看 一 下 NameServer 的 源码 目录 〈 见 图 10-1) 。 
NamesrvStartup 是 模块 的 启动 入 口 ，NamesrvController 是 用 来 协 块 
各 个 调 模 功 能 的 代码 。 


我 们 从 启动 代码 开始 分 析 ， 找 到 NamesrvStartup.java 里 的 main 函 数 
public static void main (String[Jargs) {main0 (args) ; }， 发 现 它 叉 把 逻 
辑 转 到 main0 这 个 函数 里 。 





了 Denamesrv [rocketmq-namesrv] 
v Msrc 
v MM main 
v java 
v Borg.apache.rocketmq.namesrv 
了 B kvconfig 
© KVConfigManager 
© KVConfigSerializeWrapper 
vY B processor 
© ClusterTestRequestProcessor 
© DefaultRequestProcessor 
v B routeinfo 
© BrokerHousekeepingService 
> (© RoutelnfoManager.java 
© NamesrvController 
@ NamesrvStartup 
> test 
M pom.xml 
f rocketmq-namesrv.im| 


图 10-1 NameServer 源 码 目录 


ee cee aes 第 一 个 功能 是 解析 命令 行 参 数 ， 我 
们 通过 源码 来 看 一 看 ， 重 点 是 解析 -c 和 -p 参 数 ， 如 代码 清单 10-1 所 示 。 


代码 清单 10-1 解析 NameServer 命 令 行 参 数 





Options options = ServerUtil.buildCommandlineOptions(new Options()); 
commandLine = ServerUtil.parseCmdLine("mqnamesrv", args, 
buildCommandlineOptions(options), new PosixParser()); 
if (null == commandLine) { 
System.exit(-1); 
return null; 
} 
final NamesrvConfig namesrvConfig = new NamesrvConfig(); 
final NettyServerConfig nettyServerConfig = new NettyServerConfig(); 
nettyServerConfig.setListenPort (9876); 
if (commandLine.hasOption('c')) 
String file = commandLine.getOptionValue('c'); 
if (file != null) { 
InputStream in = new BufferedInputStream(new 
FileInputStream(file) ); 
properties = new Properties(); 
properties.load(in); 
MixAll.properties20bject(properties, namesrvConfig); 
MixAll.properties20bject(properties, nettyServerConfig); 
namesrvConfig.setConfigStorePath( file); 
System.out.printf("load config properties file OK, " + 
file + "%n"); 
in.close(); 


} 


} 

if (commandLine.hasOption('p')) { 
MixAll.printObjectProperties(null, namesrvConfig); 
MixAll.printObjectProperties(null, nettyServerConfig); 
System.exit(0); 





-C 命 令 行 参数 用 来 指定 配置 文件 的 位 置 ; -p 命 令 行 参数 用 来 打印 所 
有 配置 项 的 值 。 注 意 ， 用 -p 参 数 打 印 配置 项 的 值 之 后 程序 就 退出 了 ， 了 这 
是 一 个 帮助 调试 的 选项 


10.1.3 ”初始 化 NameServer 的 Controller 


main0 函 数 的 另外 一 个 功能 是 初始 化 Controller， 如 代码 清单 10-2 所 
ZN o 


代码 清单 10-2 ”初始 化 并 局 动 Controller 





// remember all configs to prevent discard 
controller .getConfiguration().registerConfig(properties) ; 
boolean initResult = controller.initialize(); 
if (!initResult) { 
controller.shutdown(); 
System.exit(-3); 


} 
Runtime.getRuntime().addShutdownHook (new ShutdownHookThread(log, 
new Callable<Void>() { 
@Override 
public Void call() throws Exception { 
controller .shutdown(); 
return null; 


})); 
controller.start(); 





根据 解析 出 的 配置 参数 ， 调 用 controller.initialize © 来 初始 化 ， 然 
后 调用 controller.start () 让 NameServer 开 始 服务 。 


还 有 一 个 逻辑 是 注册 ShutdownHookThread， 当 程序 退出 的 时 候 会 调 
用 controller.shutdown 来 做 退出 前 的 清理 工作 。 


10.2 NameServer 的 总 控 逻 辑 


NameServer 的 总 探 逻 辑 在 NamesrvController,java 代 码 中 。 
的 协调 者 ， 它 只 是 简单 地 接收 其 他 角色 报 上 来 的 状 
态 ， 然 后 根据 请 求 返 回 相 应 的 状态 。 首 先 ，NameserverController 把 执行 
线程 池 初 始 化 好 ， 如 代码 清单 10-3 所 示 。 


代码 清单 10-3 ”线程 池 初 始 化 





this.remotingExecutor = 
Executors.newFixedThreadPool(nettyServerConfig 
.getServerworkerThreads(), new ThreadFactoryImpl 
("RemotingExecutorThread_")); 
this.registerProcessor(); 


this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
NamesrvController.this.routeInfoManager .scanNotActiveBroker(); 


} 
}, 5, 10, TimeUnit.SECONDS); 
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
NamesrvController.this.kvConfigManager.printAllPeriodically(); 


} 
}, 1, 10, TimeUnit .MINUTES); 





启动 了 一 个 默认 是 8 个 线程 的 线程 池 (private int 
serverWorkerThreads=8) ， 还 有 两 个 定时 执行 的 线程 ， 一 个 用 来 扫描 失 
效 的 Broker (scanNotActiveBroker) ， 另 一 个 用 来 打印 配置 信息 
(printAllPeriodically) 。 


然后 启动 负责 通信 的 服务 remotingServer， remotingServer Hi 监听 一 些 
端口 ， 收 到 Broker、Client 等 发 过 来 的 请 求 后 ， 根 据 请 求 的 命令 ， 调 用 
不 同 的 Processor 来 处 理 。 这 些 不 同 的 处 理 逻 辑 补 放 到 上 面 初始 化 的 线程 
池 中 执行 ， 如 代码 清单 10-4 所 示 。 


代码 清单 10-4 局 动 通信 服务 ， 关 联 初始 化 的 线程 池 








this.remotingServer = new NettyRemotingServer(this.nettyServerConfig, 
this. brokerHousekeepingService) ; 


if (namesrvConfig.isClusterTest()) { 
this. remotingServer.registerDefaultProcessor (new 
ClusterTestRequestProcessor(this, namesrvConfig 
.getProductEnvName()), 
this.remotingExecutor); 
} else { 
this. remotingServer.registerDefaultProcessor (new 
DefaultRequestProcessor(this), this.remotingExecutor); 





remotingServer 是 基于 Netty 封 装 的 一 个 网 络 通信 服务 ， 要 了 解 
remoting-Server 需 要 先 对 Netty 有 个 基本 的 认 知 ， 后 面 会 单独 介绍 。 


10.3 PAL MLA eH SH 


NameServer 的 核心 业务 逻辑 ， 在 DefaultRequestProcessor.java 中 可 以 
一 目 了 然 地 看 出 。 网 络 通信 服务 模块 收 到 请 求 后 ， 就 调用 这 个 Processor 
来 处 理 ， 如 代码 清单 10-5 所 示 。 


代码 清单 10-5 ”根据 请 求 码 调用 相应 的 处 理 逻 辑 





switch (request.getCode()) { 
case RequestCode.PUT_KV_CONFIG: 
return this.putKVConfig(ctx, request); 
case RequestCode.GET_KV_CONFIG: 
return this.getkKVConfig(ctx, request); 
case RequestCode.DELETE_KV_CONFIG: 
return this.deleteKVConfig(ctx, request); 
case RequestCode.REGISTER_BROKER: 
Version brokerVersion = MQVersion.value2Version( request 
.getVersion()); 
if (brokerVersion.ordinal() >= MQVersion.Version 
.V3_0_11.ordinal()) { 
return this.registerBrokerwWithFilterServer(ctx, request); 
} else { 
return this.registerBroker(ctx, request); 


} 
case RequestCode.UNREGISTER_BROKER: 

return this.unregisterBroker(ctx, request); 
case RequestCode.GET_ROUTEINTO_BY_TOPIC: 

return this.getRouteInfoByTopic(ctx, request); 
case RequestCode.GET_BROKER_CLUSTER_INFO: 

return this.getBrokerClusterInfo(ctx, request); 
case RequestCode.WIPE_WRITE_PERM_OF_BROKER: 

return this.wipewritePermOfBroker(ctx, request); 
case RequestCode.GET_ALL_TOPIC_LIST_FROM_NAMESERVER: 

return getAllTopicListFromNameserver(ctx, request); 
case RequestCode.DELETE_TOPIC_IN_NAMESRV: 

return deleteTopicInNamesrv(ctx, request); 
case RequestCode.GET_KVLIST_BY_NAMESPACE: 

return this.getKVListByNamespace(ctx, request); 
case RequestCode.GET_TOPICS_BY_CLUSTER: 

return this.getTopicsByCluster(ctx, request); 
case RequestCode.GET_SYSTEM_TOPIC_LIST_FROM_NS: 

return this.getSystemTopicListFromNs(ctx, request); 
case RequestCode.GET_UNIT_TOPIC_LIST: 

return this.getUnitTopicList(ctx, request); 
case RequestCode.GET_HAS_ UNIT_SUB_TOPIC_LIST: 

return this.getHasUnitSubTopicList(ctx, request); 
case RequestCode.GET_HAS_UNIT_SUB_UNUNIT_TOPIC_LIST: 

return this.getHasUnitSubUnUnitTopicList(ctx, request); 
case RequestCode.UPDATE_NAMESRV_CONFIG: 

return this.updateConfig(ctx, request); 
case RequestCode.GET_NAMESRV_CONFIG: 

return this.getConfig(ctx, request); 
default: 

break; 




















逻辑 主体 是 个 switch 语 句 ， 根 据 RequestCode 调 用 不 同 的 函数 来 处 
理 ， 从 RequestCode 可 以 了 解 到 NameServer 的 主要 功能 ， 比 如 : 
REGISTER_BROKER 是 在 集群 中 新 加 入 一 个 Broker 机 器; 
GET_ROUTEINTO_BY_TOPIC 是 请 求 获取 一 个 Topic 的 路 由 信息 ; 
WIPE_WRITF_PERM_OF_BROKER 是 删除 一 个 Broker 的 写 权 限 。 


10.4 ”集群 状态 存储 


NameServer 作 为 集群 的 协调 者 ， 需 要 保存 和 维护 集群 的 各 种 元 数 
据 ， 这 是 通过 RouteInfoManager 类 来 实现 的 ， 如 代码 清单 10-6 所 示 。 


代码 清单 10-6 ”RouteInfoManager 的 存储 结构 








private final HashMap<String/* topic */, List<QueueData>> topicQueue-Table; 

private final HashMap<String/* brokerName */, BrokerData> brokerAddr-Table; 

private final HashMap<String/* clusterName */, Set<String/* brokerName 

*/>> clusterAddrTable; 

private final HashMap<String/* brokerAddr */, BrokerLiveInfo> 
brokerLiveTable; 

private final HashMap<String/* brokerAddr */, List<String>/* Filter 

Server */> filterServerTable; 

public RouteInfoManager() { 
this.topicQueueTable = new HashMap<String, List<QueueData>>(1024); 
this. brokerAddrTable = new HashMap<String, BrokerData>(128); 
this.clusterAddrTable = new HashMap<String, Set<String>>(32); 
this.brokerLiveTable = new HashMap<String, BrokerLiveInfo>(256); 
this.filterServerTable = new HashMap<String, List<String>>(256); 





每 个 结构 存储 着 一 类 集群 信息 ， 具 体 含义 在 第 5 章 有 介绍 。 了 解 
RocketMQ 各 个 角色 的 功能 后 ， 对 每 个 结构 的 处 理 逻 辑 就 好 理解 了 。 下 
面 重点 看 一 下 控制 访问 这 些 结构 的 锁 机 制 。 


锁 分 为 互 斥 锁 、 读 写 锁 ; 也 可 分 为 可 重 入 锁 、 不 可 重 入 锁 。 在 
NameServer 的 场景 中 ， 读 取 操 作 多 ， 更 改 操作 少 ， 所 以 选择 读 写 锁 能 
大 提高 效率 。 对 于 如 何 选 择 可 重 入 和 不 可 重 入 锁 ， 重 点 看 函数 间 的 调用 
关系 ， 比 如 多 次 获取 锁 的 示例 代码 ， 如 果 这 个 lock 是 不 可 重 入 的 ， 代 码 
无 法 正常 执行 ， 如 代码 清单 10-7 所 示 。 


代码 清单 10-7 多 次 获取 锁 示例 











Lock lock = new Lock(); 

public void outer() { 
lock.lock(); 
inner(); 
lock.unlock(); 


public void inner() { 
lock.lock(); 
//do something lock.unlock(); } 


} 





RouteInfoManager 中 使 用 的 是 可 重 入 的 读 写 锁 Cprivate final 
ReadWriteLock lock=new ReentrantReadWriteLock () ) ， 我 们 以 
deleteTopic 函 数 为 例 ， 看 一 下 锁 的 使 用 方式 ， 如 代码 清单 10-8 所 示 。 


代码 清单 10-8” 锁 的 使 用 方式 





public void deleteTopic(final String topic) { 
try { 
try { 
this.lock.writeLock().lockInterruptibly(); 
this. topicQueueTable.remove(topic); 
} finally { 
this.lock.writeLock().unlock(); 


} 
} catch (Exception e) { 
log.error("deleteTopic Exception", e); 





FAC BAY SRE AA Te | — “Pry 1} E, Aa fe finally {} H 
放 。 这 是 一 种 典型 的 使 用 方式 ， 我 们 可 以 参考 这 种 方式 实现 目 己 的 代 
码 。 





10.5 本章 小 结 


本 章 分 析 了 NameServer 模 块 的 源码 ，NameServer 是 一 个 功能 重要 但 
是 代码 量 不 大 的 模块 ， 所 以 选择 这 个 模块 入 手 ， 比 较 容 易 理 解 。 我 们 在 
分 析 源 码 时 ， 认 真 读 慌 一 个 模块 后 就 可 以 对 作者 的 代码 风格 、 设 计 偏 好 
等 有 基本 的 了 解 。 下 一 章 将 分 析 Client 模 块 的 源码 ， 我 们 使 用 RocketMQ 
时 经 常 需要 和 Client 模 块 打 交道 。 


Alle 最 第 用 的 消费 类 
编写 程序 消费 RocketMQ 中 消息 的 时 候 ， 最 常用 的 类 是 


DefaultMQPush-Consumer， 这 个 类 让 我 们 消费 消息 变 得 很 简单 ， 这 个 类 
到 底 默 默 地 为 我 们 做 了 哪些 事情 呢 ? 本 章 将 对 其 做 详细 分 析 。 











11.1 整体 流程 


我 们 使 用 DefaultMQPushConsumer 的 时 候 ， 一 般 流程 是 设置 好 
GroupName、NameServer 地 址 ， 以 及 订阅 的 Topic 名 称 ， 然 后 填充 
Message 处 理 函 数 ， 最 后 调用 start O 。 本 节 基 于 这 个 流程 来 分 析 源 
A o 
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DefaultMQPushConsumer 类 在 org.apache.rocketmq.client.consumer 包 
中 ， 这 个 类 担任 着 上 层 接口 的 角色 ， 有 具体 实现 都 在 
DefaultMQPushConsumerImpl 类 中 ， 如 代码 清单 11-1 所 示 。 





代码 清单 11-1 ” DefaultMQPushConsumer 接 口 类 





JEZ 
* Default constructor. 
“7 
public DefaultMQPushConsumer() { 
this(MixAll.DEFAULT_CONSUMER_GROUP, null, new 
AllocateMessageQueueAveragely()); 


} 
/** 
* Constructor specifying consumer group, RPC hook and message queue 
allocating algorithm. 


* 

* 

* @param consumerGroup Consume queue. 

* @param rpcHook RPC hook to execute before each remoting command. 

* @param allocateMessageQueueStrategy message queue allocating algorithm. 
*/ 


public DefaultMQPushConsumer (final String consumerGroup, RPCHook rpcHook, 
AllocateMessageQueueStrategy allocateMessageQueueStrategy) { 
this.consumerGroup = consumerGroup; 
this.allocateMessageQueueStrategy = allocateMessageQueueStrategy; 
defaultMQPushConsumerImpl = new DefaultMQPushConsumerImpl1(this, 
rpcHook); 
} 
SEE 
* Constructor specifying RPC hook. 
* 


* @param rpcHook RPC hook to execute before each remoting command. 
*/ 


public DefaultMQPushConsumer(RPCHook rpcHook) { 
this(MixAll.DEFAULT_CONSUMER_GROUP, rpcHook, new 
AllocateMessageQueueAveragely()); 
} 


f** 
* Constructor specifying consumer group. 
* 


* @param consumerGroup Consumer group. 
*/ 


public DefaultMQPushConsumer(final String consumerGroup) { 
this(consumerGroup, null, new AllocateMessageQueueAveragely()); 
} 





我 们 和 常用 的 是 最 后 这 个 构造 冰 数 ， 只 传 入 一 个 consumer Group 名 称 
作为 参数 ， 这 个 构造 函数 会 把 RPCHoop 设 为 空 ， 把 负载 均衡 策略 设置 成 
平均 策略 。 在 构造 函数 的 实现 中 ， 主 要 工作 是 创建 


DefaultWQPushConsumerlmpl Xt & - 


11.1.2 DefaultMQPushConsumer 的 实现 者 


DefaultMQPushConsumerImpl 有 具体 实现 了 DefaultMQPushConsumer 
的 业务 逻辑 ，DefaultMQPushConsumerImpl.java 在 
org.apache.rocketmq.client.impl.consumer 这 个 包 里 ， 本 节 接 下 来 从 start 方 
EA FAW 

首先 是 初始 化 MQClientInstance， 并 且 设 置 好 rebalance 策 略 和 
a ee 有 这 些 结构 后 才能 发 送 pull 请 求 获取 消息 ， 如 代码 清单 
11-2 有 HT 不 。 


代码 清单 11-2 ”初始 化 MQClientInstance 和 pullApiWraper 





this.mQClientFactory = MQClientManager .getIinstance() 
.getAndCreateMQClientInstance(this.defaultMQPushConsumer, 
this.rpcHook); 
this. rebalanceImpl.setConsumerGroup(this 
. defaultMQPushConsumer .getConsumerGroup()); 
this.rebalanceImpl.setMessageModel(this.defaultMQPushConsumer 
.getMessageModel()); 
this. rebalanceImpl.setAllocateMessageQueueStrategy(this 
. defaultMQPushConsumer .getAllocateMessageQueueStrategy()); 
this. rebalanceImpl.setmQClientFactory(this.mQClientFactory); 
this.pullAPIWrapper = new PullAPIwrapper ( 
mQClientFactory, 
this .defaultMQPushConsumer.getConsumerGroup(), isUnitMode 


O); 
this. pullAPIwrapper .registerFilterMessageHook 
(filterMessageHookList); 








然后 是 确定 OffsetStore。OffsetStore 里 存储 的 是 当前 消费 者 所 消费 
的 消息 在 队列 中 的 偏 移 量 ， 如 代码 清单 11-3 所 示 。 


代码 清单 11-3 ”初始 化 OffsetStore 





if (this.defaultMQPushConsumer.getOffsetStore() != null) { 
this.offsetStore = this.defaultMQPushConsumer 
.getoffsetStore(); 
} else { 
switch (this.defaultMQPushConsumer.getMessageModel()) { 
case BROADCASTING: 
this.offsetStore = new LocalFileOffsetStore(this 
-mQClientFactory, this.defaultMQPushConsumer 
.getConsumerGroup()); 
break; 
case CLUSTERING: 


this.offsetStore = new RemoteBrokerOffsetStore 
(this.mQClientFactory, this 
. defaultMQPushConsumer .getConsumerGroup()); 
break; 
default: 
break; 


} 
this.defaultMQPushConsumer.setOffsetStore(this.offsetStore) ; 


} 
this.offsetStore.load(); 








根据 消费 消息 方式 的 不 同 ，OffsetStore 的 类 型 也 不 同 。 如 果 是 
BROADCASTING 模 式 ， 使 用 的 是 LocalFileOffsetStore，Offset 存 到 本 
地 ; 如 果 是 CLUSTERING 模 式 ， 使 用 的 是 RemoteBrokerOffsetStore， 
Offset 存 到 Broker 机 器 上 。 


然后 是 初始 化 consumeMessageService， 根 据 对 消息 顺序 需求 的 不 
同 ， 使 用 不 同 的 Service 类 型 ， 如 代码 清单 11-4 所 示 。 


代码 清单 11-4 初始 化 consumeMessageService 








if (this.getMessageListenerInner() instanceof 
MessageListenerOrderly) { 
this.consumeOrderly = true; 
this.consumeMessageService = 

new ConsumeMessageOrderlyService(this, 
(MessageListenerOrderly) this 
.getMessageListenerInner()); 

} else if (this.getMessageListenerInner() instanceof 
MessageListenerConcurrently) { 
this.consumeOrderly = false; 
this.consumeMessageService = 

new ConsumeMessageConcurrentlyService(this, 
(MessageListenerConcurrently) this 
.getMessageListenerInner()); 
} 


this.consumeMessageService.start(); 





最 后 调用 MQClientInstance 的 start 方 法 ， 开 始 获取 数据 。 


11.1.3 RÄ Be 48 


获取 消息 的 逻辑 实现 在 public void pullMessage (final PullRequest 
pullRequest) 函数 中 ， 这 是 一 个 很 大 的 函数 ， 前 半 部 分 是 进行 一 些 判 
呆 ， 是 进行 流量 控制 的 逻辑 《〈 见 代码 清单 11-5) ; 中 间 是 对 返回 消息 结 
果 做 处 理 的 逻辑 ， 后 面 是 发 送 获 取消 恩 请 求 的 逻辑 。 


代码 清单 11-5 ”流量 控制 逻辑 








if (cachedMessageCount > this.defaultMQPushConsumer 
.getPullThresholdForQueue()) { 
this.executePullRequestLater (pullRequest, 
PULL_TIME_DELAY_MILLS_WHEN_FLOW_CONTROL); 
if ((queueFlowControlTimes++ % 1000) == 0) { 
log.warn( 
"the cached message count exceeds the threshold {}, so do" + 
" flow control, minOffset={}, maxOffset={}, count={}," + 
" size={} MiB, pullRequest={}, flowControlTimes={}", 
this .defaultMQPushConsumer .getPullThresholdForQueue(), 
processQueue.getMsgTreeMap().firstKey(), processQueue 
.getMsgTreeMap().lastKey(), cachedMessageCount, 
cachedMessageSizeInMiB, pullRequest, queueFlowControlTimes) ; 





} 


return; 


if (cachedMessageSizeInMiB > this.defaultMQPushConsumer 
.getPullThresholdSizeForQueue()) { 
this.executePullRequestLater (pullRequest, 
PULL_TIME_DELAY_MILLS_WHEN_FLOW_CONTROL); 
if ((queueFlowControlTimes++ % 1000) == 0) { 
log.warn( 
"the cached message size exceeds the threshold {} MiB, so" + 
" do flow control, minOffset={}, maxOffset={}, " + 
"count={}, size={} MiB, pullRequest={}, " + 
"flowControlTimes={}", 
this .defaultMQPushConsumer .getPullThresholdSizeForQueue( ) 
, processQueue.getMsgTreeMap().firstKey(), processQueue 
.getMsgTreeMap().lastKey(), cachedMessageCount, 
cachedMessageSizeInMiB, pullRequest, queueFlowControlTimes) ; 





return; 





通过 判断 未 处 理 消 息 的 个 数 和 总 大 小 来 控制 是 起 请 求 消息 。 对 
FMEA ERIE AROMEEEE. HEE 回 状 
态 ， 调 用 相应 的 处 理 方法 ， 如 代码 清单 11-6 所 示 。 


代码 清单 11-6 ”对 返回 消息 结果 做 处 理 





switch (pullResult.getPullStatus()) { 
case FOUND: 
long prevRequestOffset = pullRequest 
.getNextoffset(); 
pullRequest.setNextOffset(pullResult 
.getNextBeginOffset()); 


case NO_NEW_MSG: 
pullRequest.setNextOffset(pullResult 
.getNextBeginOffset()); 
DefaultMQPushConsumerImpl.this.correctTagsoOffset 
(pullRequest); 
DefaultMQPushConsumerImpl. this 
.executePullRequestImmediately(pullRequest); 
break; 
case NO_MATCHED_MSG: 
pullRequest.setNextOffset(pullResult 
.getNextBeginOffset()); 
DefaultMQPushConsumerImpl.this.correctTagsoOffset 
(pullRequest); 
DefaultMQPushConsumerImpl. this 
.executePullRequestImmediately(pullRequest) ; 
break; 
case OFFSET_ILLEGAL: 
log.warn("the pull request offset illegal, {} {}", 
pullRequest.toString(), pullResult.toString()); 
pullRequest.setNextOffset(pullResult 
.getNextBeginOffset()); 
oa break; 
default: 
break; 
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被 停止 ， 如 代码 清单 11-7 所 示 。 


代码 清单 11-7 发 送 pull 请 求 





try { 
this.pullAPIWrapper .pullKernelImp1( 


pullRequest.getMessageQueue(), 
subExpression, 
subscriptionData.getExpressionType(), 
subscriptionData.getSubVersion(), 
pullRequest.getNextOffset(), 
this.defaultMQPushConsumer .getPullBatchSize(), 
sysFlag, 

commitOffsetValue, 
BROKER_SUSPEND_MAX_TIME_MILLIS, 
CONSUMER_TIMEOUT_MILLIS_WHEN_SUSPEND, 
CommunicationMode.ASYNC, 

pullCallback 


) ; 

} catch (Exception e) { 
log.error("pullKernelImpl exception", e); 
this.executePullRequestLater (pullRequest, 

PULL_TIME_DELAY_MILLS_WHEN_EXCEPTION); 





11.2 ”消息 的 并 发 处 理 


本 节 重 点 看 一 下 实现 消息 并 发 处 理 的 代码 ， 并 发 处 理会 增 大 实现 流 
量 控制 、 保 证 消 恩 顺序 方面 的 难度 。 


11.2.1 并 发 处 理 过 程 


处 理 效 率 的 高 低 是 反应 Consumer 实 现 好 坏 的 重要 指标 ， 本 节 以 
Consume-MessageConcurrentlyService 类 为 例 来 分 析 RocketMQ 的 实现 方 
式 。Consume-MessageConcurrentlyService 类 在 
org.apache.rocketmdq.client.impl.consumer 包 中 。 


Ze 三 三 个 线程 池 ， 一 个 主线 程 池 用 来 正常 执行 收 到 的 消 
A, 用 e es 以 自 定义 通过 consumeThreadMin 和 consumeThreadMax 来 自 
定义 线程 个 数 。 另 外 两 个 都 是 单线 程 的 线程 池 ， 一 个 用 来 执行 推迟 消费 
的 消息 ， 另 一 个 用 来 定期 清理 超时 消息 〈15 分 钟 ) ， 如 代码 清单 11-8 所 
未， 





代码 清单 11-8 三 个 线程 池 





this.consumeExecutor = new ThreadPoolExecutor ( 
this .defaultMQPushConsumer .getConsumeThreadMin( ), 
this .defaultMQPushConsumer .getConsumeThreadMax(), 1000 * 60, 
TimeUnit.MILLISECONDS, this.consumeRequestQueue, 
new ThreadFactoryImpl("ConsumeMessageThread_")); 
this.scheduledExecutorService = 
Executors.newSingleThreadScheduledExecutor(new ThreadFactoryImp1( 
"ConsumeMessageScheduledThread_") ); 
this.cleanExpireMsgExecutors = 
Executors.newSingleThreadScheduledExecutor(new ThreadFactoryImp1( 
"CleanExpireMsgScheduledThread_") ); 





从 Broker 获 取 到 一 批 消 息 以 后 ， 根 据 BatchSize 的 设置 ， 把 一 批 消 息 
封装 到 一 个 ConsumeRequest 中 ， 然 后 把 这 个 ConsumeRequest 提 交 到 
consumeExecutor 线 程 池 中 执行 ， 如 代码 清单 11-9 所 示 。 


代码 清单 11-9 任务 分 发 逻辑 








if (msgs.size() <= consumeBatchSize) { 
ConsumeRequest consumeRequest = new ConsumeRequest (msgs, 
processQueue, messageQueue) ; 
try { 
this.consumeExecutor. submit (consumeRequest ) ; 
} catch (RejectedExecutionException e) { 
this.submitConsumeRequestLater(consumeRequest ) ; 


} else { 
for (int total = 0; total < msgs.size(); ) { 


List<MessageExt> msgThis = new ArrayList<MessageExt> 
(consumeBatchSize); 
for (int i = 0; i < consumeBatchSize; i++, total++) { 
if (total < msgs.size()) { 
msgThis.add(msgs.get(total)); 
} else { 
break; 
} 


ConsumeRequest consumeRequest = new ConsumeRequest(msgThis, 
processQueue, messageQueue); 
try { 
this.consumeExecutor. submit (consumeRequest ) ; 
} catch (RejectedExecutionException e) { 
for (; total < msgs.size(); total++) { 
msgThis.add(msgs.get(total)); 


this.submitConsumeRequestLater(consumeRequest ) ; 





消息 的 处 理 结 果 可 能 有 不 同 的 值 ， 主 要 的 两 个 是 
CONSUME_SUCCESS 和 RECONSUME LATER。 如 果 消 费 不 成 功 ， 要 
把 消息 提交 到 上 面 说 的 scheduledExecutorService 线 程 池 中 ，5 秒 后 再 执 
行 ， 如 果 消 费 模 式 是 CLUSTERING 模 式 ， 未 消费 成 功 的 消息 会 先 被 发 
送 回 Broker， 供 这 个 ConsumerGroup 里 的 其 他 Consumer 消 费 ， 如 果 发 送 
回 Broker 失 败 ， 再 调用 RECONSUME_LATER， 消 息 消 费 的 Status 处 理 逻 
辑 如 代码 清单 11-10 所 示 。 


代码 清单 11-10 ”消息 消费 的 Status 处 理 逻 辑 





switch (this.defaultMQPushConsumer.getMessageModel()) { 
case BROADCASTING: 
for (int i = ackIndex + 1; i < consumeRequest.getMsgs().size 
(); i++) { 
MessageExt msg = consumeRequest.getMsgs().get(i); 
log.warn( "BROADCASTING, the message consume failed, drop " + 
"it, {}", msg.toString()); 
} 
break; 
case CLUSTERING: 
List<MessageExt> msgBackFailed = new ArrayList<MessageExt> 
(consumeRequest ..getMsgs().size()); 
for (int i = ackIndex + 1; i < consumeRequest.getMsgs().size 
(); i++) { 
MessageExt msg 
boolean result 
if (!result) { 
msg.setReconsumeTimes(msg.getReconsumeTimes() + 1); 
msgBackFailed.add(msg); 


consumeRequest .getMsgs().get(i); 
this.sendMessageBack(msg, context); 


} 


} 
if (!msgBackFailed.isEmpty()) { 
consumeRequest.getMsgs().removeAll(msgBackFailed) ; 


this .submitConsumeRequestLater (msgBackFailed, 
consumeRequest ..getProcessQueue(), consumeRequest 
.getMessageQueue( )); 
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的 高 低 影响 系统 的 厨 吐 量 。 可 以 把 多 条 消息 组 合 起 来 处 理 ， 或 者 提高 线 
程 数 ， 以 提高 系统 的 吞吐 量 。 





11.2.2 ProcessQueuext & 


在 前 面 的 源码 中 ， 有 个 ProcessQueue 类 型 的 对 象 ， 这 个 对 象 的 功能 
是 什么 呢 ? 从 Broker 获 得 的 消息 ， 因 为 是 提交 到 线程 池 里 并 行 执行 ， 很 
难 监控 和 控制 执行 状态 ， 比 如 如 何 获得 当前 消息 堆积 的 数量 ， 如 何 解 诀 
处 理 超时 情况 等 。RocketMQ 定 义 了 一 个 快照 类 ProcessQueue 来 解决 这 些 
问题 ， 在 PushConsumer 运 行 的 时 候 ， i Message Queue 部 会 有 一 个 对 
a 的 ProcessQueue 对 象 ， 保 存 了 这 个 Message Queue 消 息 处 理 状 态 的 快 
照 ， 如 代码 清单 11-11 所 示 。 


ProcessQueue 对 象 里 主要 的 内 容 是 o eeM ik 写 锁 。 
TreeMap 里 以 Message Queue 的 Offset 作 为 Key， 以 消息 内 容 的 引用 
Value， 保 存 了 所 有 从 MessageQueue 获 取 到 但 是 还 未 被 处 理 的 消息 ， 
写 锁 控 制 着 多 个 线程 对 TreeMap 对 象 的 并 发 访问 。 


代码 清单 11-11 保存 消息 消费 的 状态 








private final ReadWriteLock lockTreeMap = new ReentrantReadwriteLock(); 

private final TreeMap<Long, MessageExt> msgTreeMap = new TreeMap<Long, MessageExt>(° 
private final AtomicLong msgCount = new AtomicLong(); 

private final AtomicLong msgSize = new AtomicLong(); 

private final Lock lockConsume = new ReentrantLock(); 





有 了 ProcessQueue 对 象 ， 可 以 随时 集 止 、 局 消息 的 消费 ， 同 时 也 
可 用 于 帮助 实现 顺序 消费 消息 。 顺 序 消 妃 是 通 
ConsumeMessageOrderlyService 类 实现 的 ， aon 
ConsumeMessageConcurrentlyService 类 似 ， 区 别 只 是 在 对 并 发 消费 的 控 
制 上 。 





11.3 ”生产 者 消费 者 的 的 层 类 


无 论 是 生产 者 还 是 消费 者 ， 在 确 层 痢 要 和 Broker 打 交道 ， 进 行 消 忆 
收 友 。 在 源码 层面 ， 捕 层 的 功能 被 抽象 成 同一 个 类 ， 人 负 员 和 Broker 打 交 
道 ， 本 节 详 细 介 绍 这 个 类 的 情况 。 


11.3.1 MQClientInstance 类 的 创建 规则 


MQClientInstance 是 客户 端 各 种 类 型 的 Consumer 和 Producer 的 底层 
类 。 这 个 类 首先 从 NameServer 获 取 并 保存 各 种 配置 信息 ， 比 如 Topic 的 
Route 信息 。 同 时 MQClientInstance 还 会 通过 MQClientAPIImpl 类 实现 消 
县 的 收发 ， 也 惑 是 从 Broker 获 取消 息 或 者 发 送 消息 到 Broker。 


既然 MQClientInstance 实 现 的 是 底层 通信 功能 和 获取 并 保存 元 数据 
的 功能 ， 就 没 必要 每 个 Consumer 或 Producer 都 创建 一 个 对 象 ， 一 个 
MQClientInstance 对 象 可 以 被 多 个 Consumer 或 Producer 公 用 。RocketMQ 
通过 一 个 工厂 类 达到 共用 MQClientInstance 的 目的 。MQClientInstance 的 
创建 如 代码 清单 11-12 所 示 。 


代码 清单 11-12 ”创建 MQClientInstance 











MQClientManager .getInstance().getAndCreateMQClientInstance(this.defaultMQProducer, r 





注意 ，MQClientInstance 是 通过 工厂 类 被 创建 的 ， 并 不 是 一 个 单 例 
模式 ， 有 些 情况 下 需要 创建 多 个 实例 。 首 先 来 看 看 MQClientInstance 的 
创建 规则 ， 如 代码 清单 11-13 所 示 。 


代码 清单 11-13” MQClientInstance 创 建 规则 





public MQClientInstance getAndCreateMQClientInstance( 
final ClientConfig clientConfig, RPCHook rpcHook) { 
String clientId = clientConfig.buildMQClientId(); 
MQClientInstance instance = this.factoryTable.get(clientId) ; 
if (null == instance) { 
instance = 
new MQClientInstance(clientConfig.cloneClientConfig(), 
this. factoryIndexGenerator.getAndIncrement(), clientId, 
rpcHook); 
MQClientInstance prev = this.factoryTable.putIfAbsent(clientId, 
instance); 
if (prev != null) { 
instance = prev; 
log.warn( "Returned Previous MQClientInstance for " + 
"clientId:[{}]", clientId); 
} else { 
log.info("Created new MQClientInstance for clientId:[{}]", 
clientId); 
} 


} 


return instance; 





系统 中 维护 了 ConcurrentMap<String/*clientId*/， 
MQClientInstance>factoryTable 这 个 Map 对 象 ， 每 创建 一 个 新 的 
MQClientInstance， 都 会 以 clientId 作 为 a Mar 吉 构 中 。clientId 的 格 
ti 是 “clientIp”+@+“InstanceName”， 其 中 dientIp 是 客户 端 机 器 的 IP 地 

， 一 般 不 会 变 ，instancename 有 默认 值 ， 也 可 以 被 手动 设置 。 


通 情况 下 ， 一 个 用 到 RocketMQ 客 户 端的 Java 程 序 ， 或 者 说 一 个 
4 要 有 一 个 MQClientInstance 实 例 就 够 了 。 这 时 候 创建 一 个 或 
多 个 Consumer 或 者 Producer， 底 层 使 用 的 是 同一 个 MQClientInstance 实 
例 。 


在 quick start X44 F 8 4 — *DefaultMQPushConsumerKiZ2 495 Eh, 
没有 设置 这 个 Consumer 的 InstanceName 参 数 (通过 setInstanceName 函 数 
进行 设置 ) ， 这 个 时 候 InstanceName 的 值 是 默认 的 “DEFAULT”。 实 际 创 
建 的 MQClientInstance 个 数 由 设 定 的 逻辑 进行 控制 。InstanceName 的 生成 
逻辑 如 代码 清单 11-14 所 示 。 


代码 清单 11-14 ”InstanceName 生 成 逻辑 





if (this.defaultMQPushConsumer .getMessageModel() == MessageModel.CLUSTERING) { 
this .defaultMQPushConsumer .changeInstanceNameToPID(); 


public void changeInstanceNameToPID() { 
if (this.instanceName.equals("DEFAULT")) { 
this.instanceName = String.valueOf(UtilAll.getPid()); 





从 InstanceName 的 创建 逻辑 就 可 以 看 出 ， 如 果 创 建 Consumer 或 者 
Producer 类 型 的 时 候 不 手动 指定 InstanceName， 进 程 中 只 会 有 一 个 
MQClientInstance 对 象 。 


有 些 情况 下 只 有 一 个 MQClientInstance 对 象 是 不 够 的 ， 比 如 一 个 Java 
程序 需要 连接 两 个 RoceketMQ 集 群 ， 从 一 个 集群 读 取 消 恩 ， 发 送 到 男 一 
个 集群 ， 一 个 MQClientInstance 对 象 无 法 文 持 这 种 场景 。 这 种 情况 下 一 
定 要 手动 指定 不 同 的 InstanceName， 底 层 会 创建 两 个 MQClientInstance 对 


o 





11.3.2 MQClientInstance 类 的 功能 


首先 来 看 一 下 MQClientInstance 类 的 Start 函 数 ， 从 Start 函 数 中 的 逻辑 
能 大 致 了 解 MQClientInstance 类 的 功能 ， 如 代码 清单 11-15 所 示 。 


代码 清单 11-15” MQClientInstance 类 Start 函 数 





public void start() throws MQClientException { 
synchronized (this) { 
switch (this.serviceState) { 
case CREATE_JUST: 

this.serviceState = ServiceState.START_FAILED; 

// If not specified, looking address from name server 

if (null == this.clientConfig.getNamesrvAddr()) { 
this.mQClientAPIImpl.fetchNameServerAdadr(); 


// Start request-response channel 
this.mQClientAPIImpl.start(); 
// Start various schedule tasks 
this.startScheduledTask(); 
// Start pull service 
this.pullMessageService.start(); 
// Start rebalance service 
this.rebalanceService.start(); 
// Start push service 
this.defaultmMQProducer .getDefaultMQProducerImpl().start (false); 
log.info("the client factory [{}] start OK", this.clientId); 
this.serviceState = ServiceState.RUNNING; 
break; 
case RUNNING: 
break; 
case SHUTDOWN_ALREADY: 
break; 
case START_FAILED: 
throw new MQClientException("The Factory object[" + this.getClientIc 
default: 
break; 











Start 函 数 中 的 MQClientAPIImpl 对 象 用 来 负 贡 底层 消息 通信 ， 然 后 
启动 pullMessageService 和 rebalanceService。 在 类 的 成 员 变 量 中 ， 用 
topicRouteTable、brokerAddrTable 等 来 存储 从 NameServer 中 获得 的 集群 
状态 信息 ， 并 通过 一 个 ScheduledTask 来 维护 这 些 信 息 。 
MGQClientInstance 中 定时 执行 的 任务 如 代码 清单 11-16 所 示 。 


代码 清单 11-16 ”MQClientInstance 中 定时 执行 的 任务 








private void startScheduledTask() { 
if (null == this.clientConfig.getNamesrvAddr()) { 
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
try { 
MQClientInstance.this.mQClientAPIImp1 
. fetchNameServerAdadr(); 
} catch (Exception e) { 
log.error("ScheduledTask fetchNameServerAddr " + 
"exception", e); 


i } 
}, 1000 * 10, 1000 * 60 * 2, TimeUnit.MILLISECONDS) ; 


this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
try { 
MQClientInstance.this.updateTopicRouteInfoFromNameServer(); 
} catch (Exception e) { 
log.error("ScheduledTask " + 
"updateTopicRouteInfoFromNameServer exception", e); 


} 


} 
}, 10, this.clientConfig.getPollNameServerInterval(), TimeUnit 
. MILLISECONDS) ; 
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
try { 
MQClientInstance.this.cleanOfflineBroker(); 
MQClientInstance.this.sendHeartbeatToAl1BrokerwithLock(); 
} catch (Exception e) { 
log.error("ScheduledTask sendHeartbeatToAllBroker " + 
"exception", e); 


} 


} 
}, 1000, this.clientConfig.getHeartbeatBrokerInterval(), TimeUnit 
. MILLISECONDS) ; 


this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
try { 
MQClientInstance.this.persistAllConsumerOffset(); 
} catch (Exception e) { 
log.error("ScheduledTask persistAllConsumerOffset " + 
"exception", e); 


} 


} 
}, 1000 * 10, this.clientConfig.getPersistConsumerOffsetinterval(), 
TimeUnit .MILLISECONDS) ; 
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
try { 
MQClientInstance.this.adjustThreadPool(); 
} catch (Exception e) { 
log.error("ScheduledTask adjustThreadPool exception", e); 


} 
}, 1, 1, TimeUnit .MINUTES) ; 


a 从 代码 中 可 以 看 出 ，MQClientInstance 会 定时 进行 如 下 几 个 操作 : 
获取 NameServer 地 址 、 更 新 TopicRoute 信 息 、 清 理 离 线 的 Broker 和 保存 
消费 者 的 Offset。 


114 Raa 


本 章 分 析 的 是 Client 模 块 里 的 代码 ， 我 们 在 使 用 RocketMQ 的 时 候 ， 
更 多 的 是 和 这 个 模块 里 的 代码 打交道 。 本 章 重 点 分 析 了 
DefaultMQPushConsumerImpl 类 ， 然 后 分 析 了 Consumer 的 并 发 处 理 过 
程 ， 最 后 分 析 了 客户 端 Class 统 一 的 底层 通信 类 MQClientInstance。 下 一 
章 将 从 代码 层面 分 析 RocketMQ 的 主 从 同步 机 制 。 


第 12 章 ” 主 从 同步 机 制 


RocketMQ 的 Broker 分 为 Master 和 Slave 两 个 角色 ， 为 了 保证 高 可 用 
性 ，Master 角 色 的 机 器 接收 到 消息 后 ， 要 把 内 容 同步 到 Slave 机 器 上 ， 这 
样 一 旦 Master 宕 机 ，Slave 机 器 依然 可 以 提供 服务 。 本 章 分 析 Master 和 
Slave 角 色 机 器 间 同 步 功 能 实现 的 源码 。 


12.1 同步 属 性 信息 sy 


Slave 需 要 和 Master 同 步 的 不 只 是 消息 本 号 ， 一 些 元 数据 信息 也 需要 
同步 ， 比 如 TopicConfig 信 息 、ConsumerOffset 信 息 、DelayOffset 和 和 
SubscriptionGroupConfig 信 息 。Broker 在 启动 的 时 候 ， 判 断 自己 的 角色 是 
否 是 Slave， 是 的 话 就 启动 定时 同步 任务 ， 如 代码 清单 12-1 所 示 。 


代码 清单 12-1 ” ”Slave 角色 定时 同步 元 数据 信息 

















if (BrokerRole.SLAVE == this.messageStoreConfig.getBrokerRole()) { 
if (this.messageStoreConfig.getHaMasterAddress() != null && this.messageStoreCor 
this.messageStore.updateHaMasterAddress(this.messageStoreConfig.getHaMaster/ 
this.updateMasterHAServerAddrPeriodically = false; 
} else { 
this.updateMasterHAServerAddrPeriodically = true; 


this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 
try { 
BrokerController.this.slaveSynchronize.syncAll(); 
} catch (Throwable e) { 
log.error("ScheduledTask syncAll slave exception", e); 


} 
}, 1000 * 10, 1000 * 60, TimeUnit.MILLISECONDS); 





在 syncAll 函 数 里 ， 调 用 syncTopicConfig © 
syncConsumerOffset ©) ~ syncDelayOffset 〈) 和 
syncSubscriptionGroupConfig O 进行 元 数据 同步 。 我 们 以 
syncConsumerOffset 为 例 ， 来 看 看 底层 的 具体 实现 ， 如 代码 清单 12-2 所 
7 


代码 清单 12-2 syncConsumerOffset 具 体 实 现 





public ConsumerOffsetSerializeWrapper getAllConsumerOffset ( 
final String addr) throws InterruptedException, RemotingTimeoutException, 
RemotingSendRequestException, RemotingConnectException, MQBroker-Exception { 
RemotingCommand request = RemotingCommand.createRequestCommand(RequestCode.GET_/ 


RemotingCommand response = this.remotingClient.invokeSync(addr, request, 3000); 
assert response != null; 


switch (response.getCode()) { 
case ResponseCode.SUCCESS: { 
return ConsumerOffsetSerializewrapper .decode(response.getBody(), Consume 
} 


default: 
break; 


} 
throw new MQBrokerException(response.getCode(), response.getRemark()); 


} 





sysConsumer Offset ©) 的 基本 逻辑 是 组 闭 一 个 
RemotingCommand， 底 层 通过 Netty 将 消息 发 送 到 Master 角 色 的 Broker， 
然后 获取 Offset 信 息 。 


12.2 ”同步 消息 体 


本 节 介 绍 Master 和 Slave 之 间 同 步 消 恩 体内 容 的 方法 ， 也 就 是 同步 
CommitLog 内 容 的 方法 。 Corio Ta e 不 同 : 首先 ， 
CommitLog 的 数据 量 比 元 数据 要 大 ; 其 次 ， 对 实时 性 和 可 靠 性 要 求 也 不 
一 样 。 元 数据 信息 是 定时 同步 的 ， 在 两 次 同步 的 时 间 差 里 ， 如 果 出 现 异 
常 可 能 会 造成 Master 上 的 元 数据 内 容 和 Slave 上 的 元 数据 内 容 不 一 致 ， 不 
过 这 种 情况 还 可 以 补救 (手动 调整 Offset， 重 启 Consumer 等 ) 。 
CommitLog 在 高 可 靠 性 场景 下 如 果 没 有 及 时 同步 ， 一 日 Master 机 器 出 故 
障 ， 消 息 束 彻底 丢失 了 。 所 以 有 专门 的 代码 来 实现 Master 和 Slave 之 间 消 
IRA A AY Ted 


主要 的 实现 代码 在 Broker 模 块 的 org.apache.rocketmq.store. ha 包 
里 面包 括 HAService、HAConnection 和 WaitNotifyObject 这 三 个 类 











HAService 是 实现 commitLog 同 步 的 主体 ， 它 在 Master 机 器 和 Slave 机 
器 上 执行 的 逻辑 不 同 ， 默 认 是 在 Master 机 器 上 执行 ， 见 代码 清单 12-3。 


代码 清单 12-3 ”根据 Broker 角 色 ， 确 定 是 人 否 设 置 HaMasterAddress 





if (BrokerRole.SLAVE == this.messageStoreConfig.getBrokerRole()) { 

if (this.messageStoreConfig.getHaMasterAddress() != null && this.messageStoreCor 
.getHaMasterAddress().length() >= 6) { 
this.messageStore.updateHaMasterAddress(this.messageStoreConfig.getHaMaster/ 
this.updateMasterHAServerAddrPeriodically = false; 

} else { 
this.updateMasterHAServerAddrPeriodically = true; 

} 





当 Broker 角 色 是 Slave 的 时 候 ，MasterAddr 的 值 会 被 正确 设置 ， 这 样 
HAService 在 启动 的 时 候 ， 在 HAClient 这 个 内 部 类 中 ，connectMaster 会 
被 正确 执行 ， 如 代码 清单 12-4 所 示 。 


代码 清单 12-4” ”Slave 角色 连接 Master 





private boolean connectMaster() throws ClosedChannelException { 
if (null == socketChannel) { 
String addr = this.masterAddress.get(); 
if (addr != null) { 


SocketAddress socketAddress = RemotingUtil.string2SocketAddress(addr ) ; 
if (socketAddress != null) { 
this.socketChannel = RemotingUtil.connect(socketAddress); 
if (this.socketChannel != null) { 
this.socketChannel.register(this.selector, SelectionKey.OP_READ' 
} 


j J 
this.currentReportedOffset = HAService.this.defaultMessageStore.getMaxPhyOff 
this.lastWriteTimestamp = System.currentTimeMillis(); 


return this.socketChannel != null; 





从 代码 中 可 以 看 出 ，HAClient 试 图 通过 Java NIO 函 数 去 连接 Master 
角色 的 Broker。Master 角 色 有 相应 的 监听 代码 ， 如 代码 清单 12-5 所 示 。 


代码 清单 12-5 ”监听 Slave 的 HA 连接 





SER 
* Starts listening to slave connections. 
* 


* @throws Exception If fails. 
£y 


public void beginAccept() throws Exception { 
this.serverSocketChannel = ServerSocketChannel.open(); 
this.selector = RemotingUtil.openSelector(); 
this.serverSocketChannel.socket().setReuseAddress(true); 
this.serverSocketChannel.socket().bind(this.socketAddressListen) ; 
this.serverSocketChannel.configureBlocking( false); 
this.serverSocketChannel.register(this.selector, SelectionKey.OP_ACCEPT) ; 








CommitLog 的 同步 ， 不 是 经 过 netty command 的 方式 ， 而 是 直接 进行 
TCP 连 接 ， 这 样 效率 更 高 。 连 接 成 功 以 后 ， 通 过 对 比 Master 和 Slave 的 
Offset， 不 断 进 行 同步 。 


12.3 sync_master#!lasync_master 


sync_master 和 async_master 是 写 在 Broker 配 置 文件 里 的 配置 参数 ， 

这 个 参数 影响 的 是 主 从 同步 的 方式 。 从 字面 意思 理解 ，sync_master 是 同 
步 方式 ， 也 就 是 Master 角 色 Broker 中 的 消息 要 立刻 同步 过 去 ; 
async_master 是 异步 方式 ， 也 就 是 Master 角 色 Broker 中 的 消息 是 通过 异步 
处 理 的 方式 同步 到 Slave 角 色 的 机 器 上 的 。 下 面 结合 代码 来 分 析 ， 
sync_master 下 的 消息 同步 如 代码 清单 12-6 所 示 。 


代码 清单 12-6 sync_master 下 的 消息 同 








public void handleHA(AppendMessageResult result, 
PutMessageResult putMessageResult, MessageExt messageExt) { 
if (BrokerRole.SYNC_MASTER == this.defaultMessageStore 
.getMessageStoreConfig().getBrokerRole()) { 
HAService service = this.defaultMessageStore.getHaService(); 
if (messageExt.iswaitStoreMsgOK()) { 
// Determine whether to wait 
if (service.isSlaveOK(result.getwroteOffset() + result 
.getWroteBytes())) { 
GroupCommitRequest request = new GroupCommitRequest 
(result.getWroteOffset() + result 
.getWroteBytes()); 
service. putRequest(request); 
service.getwaitNotifyObject().wakeupAll(); 
boolean flushOK = 
request .waitForFlush(this.defaultMessageStore 
.getMessageStoreConfig().getSyncFlushTimeout()); 
if (!flushokK) { 
log.error("do sync transfer other node, wait return, " + 
"but failed, topic: " + messageExt 
.getTopic() + " tags: " 
+ messageExt.getTags() + " client address: 
messageExt.getBornHostNameString()); 
putMessageResult .setPutMessageStatus(PutMessageStatus 
. FLUSH_SLAVE_TIMEOUT ); 


W + 


} 


} 
// Slave problem 
else { 
// Tell the producer, slave not available 
putMessageResult.setPutMessageStatus(PutMessageStatus 
. SLAVE_NOT_AVATLABLE ) ; 





在 CommitLog 类 的 putMessage 函 数 末 尾 ， 调 用 handleHA 函 数 。 代 码 
中 的 关键 词 是 wakeupAl 和 waitForFlush， 在 同步 方式 下 ，Master 每 次 写 





消息 的 时 候 ， 都 会 等 待 癌 Slave 同 步 消 息 的 过 程 ， 同 步 完 成 后 再 返回 ， 
如 代码 清单 12-7 所 示 。 (putMessage 函 数 比较 长 ， 仅 列 出 关键 的 代 


但 ) 。 


代码 清单 12-7 putMessage 中 调用 handleHA 





publ 


ic PutMessageResult putMessage(final MessageExtBrokerInner msg) { 

// Set the storage time 
msg.setStoreTimestamp(System.currentTimeMillis()); 

// Set the message body BODY CRC (consider the most appropriate setting 
// on the client) 

msg.setBodyCRC(UtilAl1l.crc32(msg.getBody())); 

// Back to Results 

AppendMessageResult result = null; 


StoreStatsService storeStatsService = this.defaultMessageStore 
.getStoreStatsService(); 


String topic = msg.getTopic(); 
int queueId = msg.getQueueld(); 


handleDiskFlush(result, putMessageResult, msg); 
handleHA(result, putMessageResult, msg); 


return putMessageResult; 
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本 章 分 析 了 Master 和 Slave 角 色 的 Broker 之 间 同 步 信 息 功 能 的 实现 。 
需要 同步 的 信息 分 为 两 种 类 型 ， 实 现 方式 各 不 相同 : 一 种 是 元 数据 信 
轧 ， 采 用 基于 Netty 的 command 方 式 来 同步 消息 ， 另 一 种 是 commitLog 信 
E, HESAR Java NIO 来 实现 。 下 一 章 将 介绍 RocketMQ 底 
ii fa St ASH o 








第 13 章 ”基于 Netty 的 通信 实现 


本 章 分 析 RocketMQ 底 层 通信 的 实现 机 制 ， 作 为 一 个 分 布 式 消息 队 
列 ， 通 信 的 质量 至 关 重 要 。 基 于 TCP 协 议和 Socket 实 现 一 个 高 效 、 稳 定 
的 通信 程序 并 不 容易 ， 有 很 多 大 大 小 小 的 “ 坑 * 等 待 着 经 验 不 足 的 开发 
者 。RocketMQ 选 择 不 重复 发 明 轮 子 ， 基 于 Netty 库 来 实现 底层 的 通信 功 


AB 
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13.1 Netty 介 绍 


Netty 是 一 个 网 络 应 用 框架 ， 或 者 说 是 一 个 Java 网 络 开发 库 。Netty 
提供 异步 事件 驱动 的 方式 ， 使 用 它 可 以 快速 地 开发 出 高 性 能 的 网 络 应 用 
比如 客户 端 / 服 务 器 自 定 义 协议 程序 ， 大 大 简化 了 网 络 程序 的 开 

WHE 


Netty 是 一 个 精心 设计 的 框架 ， 它 从 许多 协议 实现 中 吸收 了 丰富 的 
经 验 ， 比 如 FTP、SMTP、HTTP 等 许多 基于 二 进 制 和 文本 的 传统 协议 。 
借助 Netty， 可 以 比较 容易 地 开发 出 达到 Java 网 络 专家 + 并 发 编程 专家 水 
平 的 通信 程序 。 


了 解 Netty 前 需要 对 Java NIO 有 个 基本 的 了 解 ， 熟 悉 Channel、 
ByteBuffer、Selector 等 基本 概念 。 对 于 Java 网 络 编程 经 验 不 多 的 读者 ， 
可 以 试 着 和 完 用 Java NIO 的 基本 类 写 一 个 简单 的 ClientServer 程 序 ， 然 后 再 
用 Netty 对 比 着 实现 一 过， 这 样 比较 容易 理解 Netty 里 各 种 组 件 存在 的 原 








13.2 ”Netty 架 构 忌 哆 


如 图 13-1 所 示 ，Netty 主 要 分 为 三 部 分 : 一 是 底层 的 零 找 贝 技 术 和 统 
一 通信 和 模型， 二 是 基于 JVM 实 现 的 传输 层 ;， 三 是 常用 协议 支持 。 读 者 可 
以 参考 架构 图 做 一 个 基本 的 了 解 ， 如 果 读 者 想 深入 了 解 的 话 可 以 阅读 一 
些 专门 介绍 Netty 的 书籍 。 


Protocol Support 


Transport Services 


Core 








图 13-1 Netty 整 体 架 构 
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13.2.1 重新 实现 ByteBuffer 


在 网 络 通信 中 ，CPU 处 理 数据 的 速度 大 大 快 于 网 络 传输 数据 的 速 
度 ， 所 以 需要 引入 缓冲 区 ， 将 网 络 传输 的 数据 放 入 缓冲 区 ， 款 积 足 够 的 
数据 再 发 给 CPU 处 理 。 


Netty 使 用 自己 重新 实现 的 buffer API， 而 不 是 使 用 NIO 的 ByteBuffer 
来 表示 一 个 连续 的 字 节 序列 。 新 实现 的 buffer 类 型 ByteBuf 可 以 从 底层 解 
决 ByteBuffer 的 一 些 问 题 ， 是 一 种 更 适合 日 党 网 络 应 用 开发 需要 的 缓存 
类 型 。 重 新 实现 的 ByteBuf 特 性 包括 允许 使 用 自 定义 的 缓存 类 型 、 透 明 
的 零 找 贝 实现 、 比 ByteBuffer 更 快 的 响应 速度 等 。 


字 节 缓存 在 网 络 通 信 中 会 被 频繁 地 使 用 ，ByteBuf 实 现 的 是 一 个 非 
常 轻 量 级 的 字 节 数组 包装 器 。ByteBuf 有 读 操作 和 写 操作 ， 为 了 便于 用 
户 使 用 ， 该 绥 冲 区 维护 了 读 索 引 和 写 索 引 。ByteBuf 由 三 个 片段 构成 : 
废弃 段 、 可 读 段 和 可 写 段 。 其 中 ， 可 读 段 表示 绥 冲 区 实际 存储 的 可 用 数 
据 。 当 用 户 使 用 read 或 者 skip 方 法 时 ， 将 会 增加 读 索 引 。 读 索引 之 前 的 
数据 将 进入 废弃 段 ， 表 示 访 数据 已 被 使 用 过 了 。 此 外 ， 用 户 可 主动 使 用 
discardReadBytes 清 空 废弃 段 以 便 得 到 更 多 的 可 写 空间 。 简 单 来 说 和 
ByteBuffer 相 比 ，ByteBuf 用 在 网 络 编程 时 更 合适 ， 更 易 用 。 











13.2.2 ”统一 的 异步 IO 接 口 


传统 的 Java VO API 在 应 对 不 同 的 传输 协议 时 需要 使 用 不 同 的 类 型 
和 方法 。 例 如 java.net.Socket 和 java.net.DatagramSocket， 但 它们 没有 相同 
的 父 类 型 ， 因 此 需要 使 用 不 同 的 调用 方式 执行 Socket 操 作 。 因 为 在 模式 
上 不 匹配 ， 所 以 更 换 网 络 应 用 的 传输 协议 时 工作 会 变 得 很 繁杂 。 由 于 
(Java I/O API) 缺乏 协议 间 的 可 移植 性 ， 无 法 在 不 修改 网 络 传输 层 的 
前 提 下 增加 多 种 协议 的 支持 。 从 理论 上 讲 ， 多 种 应 用 层 协议 可 运行 在 多 
种 传输 层 协议 之 上 ， 例 如 TCPAIP、UDPAP、SCcCTP 和 串口 通信 。 


还 有 个 复杂 的 情况 是 ，Java 的 新 IO (NIO) API 与 原 有 的 阻塞 式 
VO (OIO) API 不 兼容 。 这 两 者 无 论 是 在 设计 上 还 是 在 性 能 上 ， 其 特性 
都 不 相同 ， 可 是 在 开发 时 一 般 只 选择 某 一 种 API。 例 如 ， 在 用 户 数 较 小 
的 时 候 可 以 选择 使 用 传统 的 OIO (Old I/O) API， 上 毕竟 与 NIO 相 比 使 用 
OIO 更 加 容易 ， 但 是 当 业 务 快速 增长 ， 服 务 器 需要 同时 处 理 成 千 上 万 的 
客户 连接 时 间 题 就 来 了 ， 这 时 候 不 得 不 尝试 使 用 NIO 来 解决 ， 新 的 NIO 
Selector 编 程 接口 和 Old WO 差别 很 大 ， 很 难 做 到 快速 升级 。 


Netty 有 一 个 被 称 为 Channel 的 统一 异步 1O 编 程 接 口 ， 这 个 编程 接口 
抽象 了 所 有 点 对 点 的 通信 操作 。 这 样 ， 如 果 应 用 是 基于 Netty 的 茶 一 种 
传输 方式 来 实现 的 ， 则 可 以 快速 迁移 到 为 一 种 传输 实现 上 。Netty 提 供 
了 儿 种 拥有 相同 编程 接口 的 基本 传输 实现 : 


:基于 NIO 的 TCP/IP 传 输 Cio.netty.channel.nio) ; 

















:基于 OIO 的 TCP/IP 传 输 Cio.netty.channel.oio) ; 
:基于 OIO 的 UDP/IP 传 输 Co.netty.channel.oio) ; 
:本 地 传输 (io.netty.channel.local) 。 


切换 不 同 的 传输 实现 通常 只 需 修 改 几 行 代码 ， 而 且 由 于 核心 API 具 
有 高 度 的 可 扩展 性 ， 很 容易 定制 自己 的 传输 实现 。 








13.2.3 ”基于 拦截 链 模式 的 事件 模型 


一 个 定义 民 好 并 具有 扩展 能 力 的 事件 模型 可 以 大 大 提高 事件 驱动 程 
序 的 效率 ，Netty 就 具有 定义 良好 的 MO 事件 模型 ， 它 采用 严格 的 层次 结 
构 来 区 分 不 同 的 事件 类 型 ，Netty 也 人 允许 在 不 破坏 现 有 代码 的 情况 下 实 
现 自己 的 事件 类 型 。 事 件 模型 是 Netty 的 一 个 亮点 ， 很 多 NIO 通 信 框 架 没 
有 或 者 仅 有 有 限 的 事件 模型 概念， 当 需 要 一 个 新 的 事件 类 型 的 时 候 常 当 
需要 修改 已 有 的 代码 ， 有 的 甚至 不 允许 进行 自 定 义 的 扩展 。 


在 Netty 中 ，ChannelPipeline 内 部 的 一 个 ChannelEvent 被 一 组 
ChannelHandler 处 理 。 这 个 管道 是 Intercepting Filter 〈 拦 截 过 滤器 ) 模式 
的 一 种 高 级 形式 的 实现 ， 因 此 对 于 一 个 事件 如 何 被 处 理 ， 以 及 管道 内 部 
处 理 器 间 的 交互 过 程 ， 用 户 拥 有 绝对 的 控制 力 。 

















13.2.4 ”高 级 组 件 


Netty 提 供 了 一 系列 的 高 级 组 件 来 让 开发 过 程 更 加 快捷 ， 比 如 Codec 
框架 、SSL/TLS 支 持 、HTTP 实 现 等 。 


首先 看 看 Codec 框 架 。 从 业务 人 逻辑 代码 中 分 离 协 议 处 理 部 分 可 以 让 
代码 结构 变 得 更 清晰 ， 但 是 如 果 从 零 开 始 实现 会 有 很 高 的 复杂 性 ， 比 如 
处 理 分 段 消 息 ， 相 互 受 加 的 多 层 协议 ， 还 有 些 协议 复杂 到 无 法 在 一 台独 
并 的 状态 机 上 实现 。Netty 提 供 了 一 组 构建 在 其 核心 模块 之 上 的 codec 实 
现 ， 征 一 种 可 扩展 、 可 重用 、 可 单元 测试 ， 并 且 是 多 层 的 codec 框 架 ， 
为 用 户 提 供 容 易 维 护 的 codec 代 码 。 


Netty 还 提供 对 SSL/TLS 的 支持 ， 不 同 于 传统 阻塞 式 的 VO 实现 ， 在 
NIO 模 式 下 文 持 SSL 功 能 不 能 只 是 简单 地 包装 一 下 流 数 据 并 进行 加 密 或 
解密 工作 ， 还 需要 借助 于 javax.net.ssl.SSLEngine。SSLEngine 是 一 个 有 
状态 的 实现 ， 使 用 SSLEngine 必 须 管 理 所 有 可 能 的 状态 ， 例 如 密码 套 
件 、 密 钥 协 商 〈 或 重新 协商 ) 、 证 书 交 换 以 及 认证 等 ， 而 且 SSLEngine 
不 是 一 个 绝对 的 线程 安全 实现 。 在 Netty 内 部 ，SslHandler 封 装 了 所 有 艰 
难 的 细节 ， 以 及 使 用 SSLEngine 可 能 带 来 的 陷阱 。 用 户 只 需要 配置 并 将 
该 SslHandler 插 入 你 的 ChannelPipeline 中 即 可 ， 而 且 Netty 人 允许 实 现 像 
StartT1S 那 样 的 高 级 特性 。 


HTTP 是 互联 网 上 最 受 欢迎 的 协议 ， 与 现 有 的 HTTP 实 现 相 比 ， 
Netty 的 HTTP 实 现 是 相当 与 众 不 同 的 。 在 HTTP 消 息 的 低层 交互 过 程 中 
用 户 拥 有 绝对 的 控制 力 ， 因 为 Netty 的 HTTP 实 现 只 是 一 些 HTTP Codec 和 
HTTP 消 息 类 的 简单 组 合 ， 不 存在 任何 限制 ， 例 如 那 种 被 迫 选择 的 线程 
模型 。 用 户 可 以 根据 自己 的 需求 编写 那 种 可 以 完全 按照 你 期 望 的 工作 方 
式 工作 的 客户 端 或 服务 器 端 代码 ， 比 如 线程 模型 、 连 接生 命 期 、 快 编码 
等 。 基 于 这 种 高 度 可 定制 化 的 特性 ， 用 户 可 以 开发 一 个 非常 高 效 的 
HTTP 服 务 器 ， 例 如 要 求 持 久 化 链接 以 及 服务 器 端 推送 技术 的 聊天 服 
务 ， 需 要 保持 链接 直至 整个 文件 下 载 完 成 的 媒体 流 服务 ， 需 要 上 传 大 文 
件 并 且 没 有 内 存 压力 的 文件 服务 ， 文 持 大 规模 混合 客户 端 应 用 用 于 连接 
以 万 计 的 第 三 方 异 步 web 服 务 等 。 


Netty 的 WebSockets 实 现 ，WebSockets 允 许 双 向 ， 全 双 工 通信 信 
道 。 在 TCP socket 中 ， 它 被 设计 为 允许 一 个 Web 浏 览 器 和 Web 服 务 器 之 
































间 通 过 数据 流 交 互 。WebSocket 协 议 已 经 被 IETF 列 为 RFC 6455 规 范 ， 并 
且 Netty 实 现 了 RFC 6455 和 一 些 老 版 本 的 规范 。 


此 外 Netty 还 支持 Google Protocol Buffer, Google Protocol Buffers 是 
快速 实现 一 个 高 效 的 二 进 制 协议 的 理想 方案 。 通 过 使 用 ProtobufEncoder 
和 ProtobufDecoder， 我 们 可 以 把 Google Protocol Buffers 编 译 需 

(protoc) 生成 的 消息 类 放 入 Netty 的 codec 实 现 中 。 


13.3 ”Netty 用 法 示例 


13.3.1 Discard 服 务 器 


世上 最 简单 的 协议 不 是 “Hello，World! ”而 是 DISCARD 服 务 器 。 这 
个 协议 会 抛弃 任何 收 到 的 数据 而 不 啊 应 。 实 现 DISCARD 协 议 只 需 忽 略 
所 有 收 到 的 数据 。 我 们 从 Handler 〈 处 理 器 ) 的 实现 开始 ，Handler 是 由 
Netty 生 成 用 来 处 理 VO 事 件 的 ， 如 代码 清单 13-1 所 示 。 


代码 清单 13-1 DiscardServerHandler 实 现 





import io.netty.buffer.ByteBuf; 

import io.netty.channel.ChannelHandlerContext; 

import io.netty.channel.ChannelInboundHandlerAdapter ; 
* k 


* 处 理 服务 端 channel. 


public class DiscardServerHandler extends ChannelInboundHandlerAdapter { // (1) 
@Override 
public void channelRead(ChannelHandlerContext ctx, Object msg) { // (2) 
// 默默 地 丢弃 收 到 的 数据 
((ByteBuf) msg).release(); // (3) 


@Override 
public void exceptionCaught (ChannelHandlerContext ctx, Throwable cause) { // (4; 
// 当 出 现 异常 就 关闭 连 


We 








cause.printStackTrace(); 
ctx.close(); 





DiscardServerHandler 继 承 自 ChannelInboundHandlerAdapter， 这 个 类 
实现 了 ChannelInboundHandler 接 口 ，ChannelInboundHandler 提 供 了 许多 
事件 处 理 的 接口 方法 ， 我 们 可 以 履 盖 这 些 方法 。 只 需要 继承 
ChannelInbound-HandlerAdapter 类 而 不 用 自己 去 实现 接口 方法 。 


1x A i SchanelRead O 事件 处 理 方法 。 每 当 从 客户 端 收 到 
新 的 数据 时 ， 这 个 方法 会 在 收 到 消 奶 时 被 调用 ， 这 个 例子 中 ， 收 到 的 消 


恩 类 型 是 ByteBuf。 


为 了 实现 DISCARD 协 议 ， 处 理 器 不 得 不 忽略 所 有 接收 到 的 消息 。 
ByteBuf 是 一 个 引用 计数 对 象 ， 这 个 对 象 必 须 显 式 地 调用 release() 方法 








TRAE IB. VERS ARTHAS AY BH oe Ae PEAT A Fe BADE AS AY S| H i BOT RR 
我 们 看 看 channelRead O 一 般 实 现 的 方法 ， 如 代码 清单 13-2 所 示 。 


代码 清单 13-2”channelRead 实 现 





@Override 
public void channelRead(ChannelHandlerContext ctx, Object msg) { 
try { 
// Do something with msg 
} finally { 
ReferenceCountUtil.release(msg) ; 
} 


} 





在 出 现 Throwable 对 象 ， 即 当 Netty 由 于 IO 错误 或 者 处 理 器 在 处 理事 
件 抛 出 异常 时 ，exceptionCaught O 事件 处 理 方法 会 被 调用 。 在 大 部 分 
情况 下 ， 捕 获 的 异 帝 应 该 被 记录 下 来 并 且 把 关联 的 Channel 关 闭 掉 。 通 
党 在 过 到 不 同 的 异常 情况 下 会 实现 不 同 的 处 理 方法 ， 比 如 可 能 想 在 关闭 
连接 之 前 发 送 一 个 错误 码 的 啊 应 消息 。 

目前 为 止 我 们 已 经 实现 了 DISCARD 服 务 器 差不多 一 半 的 功能 ， 接 
下 来 编写 一 个 main O 方法 来 启动 服务 端的 DiscardServerHandler， 如 代 
码 清 单 13-3 所 示 。 


代码 清单 13-3 ”DiscardServer 实 现 





import io.netty.bootstrap.ServerBootstrap; 

import io.netty.channel.ChannelFuture; 

import io.netty.channel.ChannelInitializer; 

import io.netty.channel.Channeloption; 

import io.netty.channel.EventLoopGroup; 

import io.netty.channel.nio.NioEventLoopGroup; 

import io.netty.channel.socket.SocketChannel; 

import io.netty.channel.socket.nio.NioServerSocketChannel; 
fiat 


* 丢弃 任何 进入 的 数据 


public class DiscardServer { 
private int port; 
public DiscardServer(int port) { 
this.port = port; 























public void run() throws Exception { 
EventLoopGroup bossGroup = new NioEventLoopGroup(); // (1) 
EventLoopGroup workerGroup = new NioEventLoopGroup(); 
try { 
ServerBootstrap b = new ServerBootstrap(); // (2) 
b.group(bossGroup, workerGroup) 
.channel(NioServerSocketChannel.class) // (3) 
.childHandler(new ChannelInitializer<SocketChannel>() { // (4) 


@Override 
public void initChannel(SocketChannel ch) throws Exception 


ch.pipeline().addLast(new DiscardServerHandler()); 


}) 

.option(ChannelOption.SO_BACKLOG, 128) // (5) 

.childOption(Channeloption.S0O_ KEEPALIVE, true); // (6) 
// 绑 定 端口 ， 开 始 接收 进来 的 连接 
ChannelFuture f = b.bind(port).sync(); // (7) 
// 等 待 服务 器 Socket 关闭 。 
// 在 这 个 例子 中 ， 这 不 会 发 生 ， 但 你 可 以 优雅 地 关闭 你 的 服务 器 。 
f.channel().closeFuture().sync(); 

} finally { 

workerGroup.shutdownGracefully(); 
bossGroup.shutdownGracefully(); 












































public static void main(String[] args) throws Exception { 
int port; 
if (args.length > 0) { 
port = Integer.parseInt(args[0]); 
} else { 
port = 8080; 


new DiscardServer(port).run(); 
} 
} 





NioEventLoopGroup 是 用 来 处 理 MVO 操 作 的 多 线程 事件 循环 器 ，Netty 
提供 了 许多 不 ` 同 的 EventLoopGroup 的 实现 来 处 理 不 ` 同 的 传输 类 型 。 在 这 
个 例子 中 我 们 实现 了 一 个 服务 端 出 的 应 用 ， 因 此 会 有 2 个 
NioEventLoopGroup 锐 使用。 第 一 个 经 常 被 叫做 “boss”， 用 来 接 收 进来 的 
连接 ; 第 二 个 经 常 被 叫 Bone 用 来 处 理 已 经 被 接收 的 连接 。 

Fl “boss” HEC HE, 束 会 把 连接 信息 注册 到 “worker” 上 。 如 何 知 道 多 
少 个 线程 已 经 被 使 用 ， 如 何 映射 到 已 经 创建 的 Channel 上 都 需 看 要 依赖 于 
EventLoopGroup 的 实现 ， 并 且 可 以 通过 构造 函数 来 配置 他 们 的 关系 。 


ServerBootstrap 是 一 个 启动 NIO 服 务 的 辅助 司 动 类 。 可 以 在 这 个 服 
务 中 直接 使 用 Channel， 但 处 理 过 程 比较 复杂 ， 一 般 不 需要 这 样 做 。 


代码 中 我 们 指定 使 用 NioServerSocketChannel 类 来 说 明 一 个 新 的 
Channel 如 何 接收 进来 的 连接 。 


这 里 的 事件 处 理 类 经 常会 被 用 来 处 理 一 个 最 近 的 已 经 接收 的 
Channel。ChannelInitializer 是 一 个 特殊 的 处 理 类 ， 他 的 目的 是 帮助 使 用 
者 配置 一 个 新 的 Channel。 我 们 可 以 通过 增加 一 些 处 理 类 比如 
DiscardServerHandler 来 配置 一 个 新 的 Channel 或 者 其 对 应 的 
ChannelPipeline 来 实现 网 络 程序 。 当 网 络 程序 变 得 复杂 时 ， 可 以 增加 更 








多 的 处 理 类 到 pipline 上 ， 然 后 提取 这 些 匿 名 类 到 最 顶层 的 类 上 。 


可 以 设置 代码 中 指定 的 Channel 的 配置 参数 ， 这 是 一 个 TCP/IP 的 服 
务 端 程序 ， 因 此 我 们 要 设置 Socket 的 参数 选项 比如 tcpNoDelay 和 
keepAlive。 详 细 内 容 可 以 参考 ChannelOption 和 ChannelConfig 实 现 的 接 
口 文 档 ， 来 对 ChannelOption 有 一 个 大 致 的 认识 。 


option () 是 提供 给 NioServerSocketChannel 用 来 接收 进来 的 连接 。 
childOption () 是 提供 给 由 父 管 道 ServerChannel 接 收 到 的 连接 ， 在 这 个 
例子 中 也 就 是 NioServerSocketChannel。 


剩 下 的 就 是 绑 定 端口 然后 启动 服务 。 这 里 是 绑 定 了 机 器 所 有 网 卡 上 
的 8080 端 口 。 现 在 也 可 以 多 次 调用 bind〈) 方法 来 绑 定 不 同 的 地 址 。 








13.3.2 ”查看 收 到 的 数据 


上 一 节 我 们 已 经 编写 了 Discard 服 务 端 ， 现 在 需要 测试 一 下 它 是 否 
的 可 以 运行 。 最 简单 的 测试 方法 是 使 用 telnet 命 令 。 例 如 可 以 在 命令 行 
上 输入 telnet localhost 8080 或 者 其 他 类 型 参数 。 但 是 我 们 不 能 确定 这 个 
服务 端 是 否 正常 运行 ， 因 为 它 是 一 个 Discard 服 务 ， 没 法 得 到 任何 响应 。 
为 了 证 明 程序 仍然 在 正常 工作 ， 我 们 需要 修改 服务 端的 程序 来 打印 出 它 
到 底 接收 到 了 什么 。 


我 们 已 经 知道 channelRead() 方法 是 在 数据 被 接收 的 时 候 调 用 。 让 
我 们 在 DiscardServerHandler 类 的 channelRead() 方法 里 添加 一 些 代 人 码 ， 
如 代码 清单 13-4 所 示 。 


代码 清单 13-4 重新 实现 channelRead 








@Override 
public void channelRead(ChannelHandlerContext ctx, Object msg) { 
ByteBuf in = (ByteBuf) msg; 
try { 
while (in.isReadable()) { // (1) 
System.out.print((char) in.readByte()); 
System.out.flush(); 


} 
} finally { 
ReferenceCountUtil.release(msg); // (2) 
} 


} 





这 个 低 效 的 循环 可 以 被 简化 为 : 
System.out.println (in.toString 〈io.netty.util.CharsetUtil.US_ASCII) ) 。 
可 以 在 这 里 调用 in.release O ， 如 果 再 次 运行 telnet 命 令 ， 我 们 就 能 
看 到 服务 端 会 打印 出 它 所 接收 到 的 消息 。 


13.4 RocketMQ 基 于 Netty 的 通信 功能 实现 


RocketMQ 底 层 通 信 的 实现 是 在 Remoting 模 块 里 ， 因 为 信 助 了 
Netty，RocketMQ 的 通信 部 分 没有 很 多 的 代码 ， 就 是 用 Netty 实 现 了 一 个 
目 定 义 协 议 的 客户 端 /服务 器 程序 。 





13.4.1 ”顶层 抽象 类 


RocketMQ 的 通信 部 分 代码 量 并 不 多 ， 代 码 结构 如 图 13-2 所 示 。 


RocketMQ 通 信 模 块 的 顶层 结构 是 RemotingServer 和 
RemotingClient， 分 别 对 应 通信 的 服务 端 和 客户 端 。 首 先 看 看 
RemotingServer， 如 代码 清单 13-5 所 示 。 


v remoting [rocketmq-remoting] 


v Msrc 
v Ba main 


v Wjava 
了 BD org.apache.rocketmq.remoting 


p 
EE 
be 


© annotation 
De common 
Be exception 


> Ea netty 


p 


> Mtest 
> Be target 
M pom.xml 


Bn protocol 

M ChannelEventListener 

mM CommandCustomHeader 
M InvokeCallback 

® RemotingClient 

@® RemotingServer 

@® RemotingService 

@® RPCHook 


ii rocketmq-remoting.iml 
图 13-2 ”Remoting 模 块 代 码 结构 


代码 清单 13-5 “RemotingService 类 





public interface RemotingServer extends RemotingService { 
void registerProcessor(final int requestCode, 
final NettyRequestProcessor processor, 


final ExecutorService executor); 
void registerDefaultProcessor(final NettyRequestProcessor processor, 


final ExecutorService executor); 

int localListenPort(); 

Pair<NettyRequestProcessor, ExecutorService> getProcessorPair ( 
final int requestCode); 

RemotingCommand invokeSync(final Channel channel, 
final RemotingCommand request, 
final long timeoutMillis) throws InterruptedException, 
RemotingSendRequestException, 
RemotingTimeoutException; 

void invokeAsync(final Channel channel, final RemotingCommand request, 
final long timeoutMillis, 
final InvokeCallback invokeCallback) throws InterruptedException, 
RemotingTooMuchRequestException, RemotingTimeoutException, 
RemotingSendRequestException; 


void invokeOneway(final Channel channel, final RemotingCommand request, 
final long timeoutMillis) 
throws InterruptedException, RemotingTooMuchRequestException, 
RemotingTimeoutException, 
RemotingSendRequestException; 





RemotingServer 类 中 比较 重要 的 是 : localListenPort. 
registerProcessor 和 registerDefaultProcessor，registerDefaultProcessor 用 来 


设置 接收 到 消息 后 的 处 理 方 法 。 


RemotingClient 类 和 RemotingServer 类 相对 应 ， 比 较 重 要 的 方法 是 
updateNameServerAddressList、invokeSync 和 invokeOneway， 
updateName-ServerAddressList 用 来 获取 有 效 的 NameServer 地 址 ， 
invokeSync 与 invokeOneway 用 来 向 Server 端 发 送 请 求 ， 如 代码 清单 13-6 
所 示 。 


代码 清单 13-6 ”RemotingClient 类 








public interface RemotingClient extends RemotingService { 

void updateNameServerAddressList(final List<String> addrs); 

List<String> getNameServerAddressList(); 

RemotingCommand invokeSync(final String addr, final RemotingCommand request, 
final long timeoutMillis) throws InterruptedException, 
RemotingConnectException, 

RemotingSendRequestException, RemotingTimeoutException; 

void invokeAsync(final String addr, final RemotingCommand request, 
final long timeoutMillis, 
final InvokeCallback invokeCallback) throws InterruptedException, 
RemotingConnectException, 

RemotingTooMuchRequestException, RemotingTimeoutException, 
RemotingSendRequestException; 

void invokeOneway(final String addr, final RemotingCommand request, 
final long timeoutMillis) 
throws InterruptedException, RemotingConnectException, 
RemotingTooMuchRequestException, 

RemotingTimeoutException, RemotingSendRequestException; 

void registerProcessor(final int requestCode, 

final NettyRequestProcessor processor, 


final ExecutorService executor); 
void setCallbackExecutor(final ExecutorService callbackExecutor) ; 
boolean isChannelwritable(final String addr); 


13.4.2 ”上 自 定义 协议 


NettyRemotingServer 和 NettyRemotingClient 分 别 实现 了 
RemotingServer 与 RemotingClient 这 两 个 接口 ， 但 它们 有 很 多 共有 的 内 
容 ， 比 如 invokeSync、invokeOneway 等 ， 所 以 这 些 共 有 函数 被 提取 到 
NettyRemotingAbstract 共 同 继承 的 父 类 中 。 首 先 来 分 析 一 下 在 
NettyRemotingAbstract 中 是 如 何 处 理 接收 到 的 内 容 的 ， 如 代码 清单 13-7 
所 示 。 


代码 清单 13-7 ”处理 请 求 消息 











public void processRequestCommand(final ChannelHandlerContext ctx, 
final RemotingCommand cmd) { 
final Pair<NettyRequestProcessor, ExecutorService> matched = this 
. processorTable.get(cmd.getCode()); 
final Pair<NettyRequestProcessor, ExecutorService> pair = null == 
matched ? this.defaultRequestProcessor : matched; 
final int opaque = cmd.getOpaque(); 





无 论 是 服务 端 还 是 客户 端 都 需要 处 理 接 收 到 的 请 求 ， 处 理 方 法 由 
processRequestCommand 定 义 ， 注 意 这 里 接收 到 的 消息 已 经 被 转换 成 
Remoting-Command 了 ， 而 不 是 原始 的 字 节 流 。 


RemotingCommand 是 RocketMQ 自 定义 的 协议 ， 具 体格 式 如 图 13-3 
所 示 。 


——— + - 














这 个 协议 只 有 四 部 分 ， 但 是 履 新 了 RocketMQ 各 个 角色 间 几 乎 所 有 
的 通信 过 程 ，RemotingCommand 有 实际 的 数据 类 型 和 各 部 分 对 应 ， 如 代 
码 清 单 13-8 所 示 。 


代码 清单 13-8 RemotingCommand 成 员 变量 


一 


private int code; 

private LanguageCode language = LanguageCode. JAVA; 

private int version = 0; 

private int opaque = requestId.getAndIncrement(); 

private int flag = 0; 

private String remark; 

private HashMap<String, String> extFields; 

private transient CommandCustomHeader customHeader; 

private SerializeType serializeTypeCurrentRPC = serializeTypeConfigInThis-Server; 
private transient byte[] body; 








RocketMQ A HAF fil} AIEEE K CE 4 A 
RemotingCommand 则 相互 转换 ， 也 就 是 编码 、 解 码 过 程 ， 好 在 Netty 提 
供 了 codec 文 持 ， 这 个 频 粽 的 操作 只 需要 一 行 设置 束 可 以 完成 : 
pipeline () addLast (new NettyEncoder () , new NettyDecoder () . 





下 面 分 析 一 下 发 送 消 息 的 实现 机 制 ， 即 同 部 发 送 方式 的 实现 ， 如 代 
码 清 单 13-9 所 示 。 


代码 清单 13-9 ”同步 方式 发 送 











public RemotingCommand invokeSyncImpl(final Channel channel, 
final RemotingCommand request, 
final long timeoutMillis) 
throws InterruptedException, RemotingSendRequestException, 
RemotingTimeoutException { 
final int opaque = request.getOpaque(); 
try { 
final ResponseFuture responseFuture = new ResponseFuture(opaque, 
timeoutMillis, null, null); 
this.responseTable.put(opaque, responseFuture); 
final SocketAddress addr = channel.remoteAddress(); 
channel.writeAndFlush(request) .addListener(new ChannelFutureListener() { 
@Override 
public void operationComplete( 
ChannelFuture f) throws Exception { 
if (f.isSuccess()) { 
responseFuture.setSendRequestOK(true) ; 
return; 
} else { 
responseFuture. setSendRequestOK( false); 


responseTable.remove(opaque) ; 

responseFuture.setCause(f.cause()); 

responseFuture.putResponse(null); 

log.warn("send a request command to channel <" + addr + 
"> failed."); 


} 
}); | l 
RemotingCommand responseCommand = responseFuture.waitResponse 
(timeoutMillis); 
if (null == responseCommand) { 
if (responseFuture.isSendRequestOK()) { 


throw new RemotingTimeoutException(RemotingHelper 
.parseSocketAddressAddr(addr), timeoutMillis, 
responseFuture.getCause()); 
} else { 
throw new RemotingSendRequestException(RemotingHelper 
. parseSocketAddressAddr(addr), responseFuture 
.getCause()); 
} 


return responseCommand; 
} finally { 

this.responseTable. remove(opaque) ; 
} 


} 





函数 的 RemotingCommand 来 自 对 要 发 送 消 息 的 封装 ， 输 入 参数 
Channel 来 自 io.netty.channel。Channel 是 通信 的 入 口 ，Channel 对 象 的 获 
取 ， 对 于 服务 端 和 客户 端 来 说 差别 很 大 。 对 客户 端 来 说 ， 由 于 是 主动 获 
取消 息 的 一 方 ， 需 要 癌 哪 个 地 址 发 送 消息 ， 于 是 通过 Netty 的 Bootstrap 方 
法 创建 一 个 连接 (同时 把 连接 后 的 Channel 保 存 起 来 ， 避 免 每 发 一 个 消 
恩 都 重新 创建 连接 ) ; 对 服务 端 来 次 ， 很 少 主动 发 送 消息 ， 服 务 端 一 直 
在 监听 某 个 端口 ， 当 有 一 个 连接 请 求 进入 后 ， 服 务 端 会 把 创建 的 
Channel 对 象 保存 下 来 ， 供 偶尔 需要 回 客 户 端 主动 发 消息 的 时 候 使 用 。 














13.4.3 ”基于 Netty 的 Server 和 Client 


基于 Netty 实 现 的 Server 或 Client 程 序 ， 有 具体 代码 在 
NettyRemotingServer 和 NettyRemotingClient 这 两 个 类 中 ， 我 们 从 
ServerBootstrap 的 初始 化 来 看 RocketMQ 是 如 何 基 于 Netty 实 现 Server 并 程 
序 的 ， 如 代码 清早 13-10 所 示 。 


代码 清单 13-10 ”ServerBootstrap 实 现 





ServerBootstrap childHandler = 
this.serverBootstrap.group(this.eventLoopGroupBoss, this 
.eventLoopGroupSelector ) 
.channel(useEpoll() ? EpollServerSocketChannel.class : 
NioServerSocketChannel.class) 
.option(ChannelOption.SO_ BACKLOG, 1024) 
.option(ChannelOption.SO_REUSEADDR, true) 
.option(ChannelOption.SO_KEEPALIVE, false) 
.childOption(ChannelOption.TCP_NODELAY, true) 
.childOption(ChannelOption.SO_SNDBUF, nettyServerConfig 
.getServerSocketSndBufSize() ) 
.childOption(ChannelOption.SO_RCVBUF, nettyServerConfig 
.getServerSocketRcvBufSize() ) 
. LocalAddress(new InetSocketAddress(this.nettyServerConfig 
.getListenPort())) 
.childHandler(new ChannelInitializer<SocketChannel>() { 
@Override 
public void initChannel(SocketChannel ch) throws Exception { 
ch.pipeline() 
.addLast (defaultEventExecutorGroup, 
HANDSHAKE_HANDLER_NAME, 
new HandshakeHandler (TlsSystemConfig.t1lsMode) ) 
.addLast (defaultEventExecutorGroup, 
new NettyEncoder(), 
new NettyDecoder(), 
new IdleStateHandler(0, 0, nettyServerConfig 
.getServerChannelMaxIdleTimeSeconds()), 
new NettyConnectManageHandler(), 
new NettyServerHandler() 
); 
} 
}); 





ServerBootStrap 的 BossEventLoop 使 用 的 是 单线 程 的 
NioEventLoopGroup，workerEventLoop 在 Linux 平 台 使 用 的 是 默认 3 个 线 
程 的 EpollEventLoopGroup， 在 非 Linux 平 台 使 用 的 是 3 个 线程 的 
NioEventLoopGroup。 在 最 后 几 行 代码 中 还 可 以 看 到 添加 了 NettyEncoder 
和 NettyDecoder 这 两 个 Handler。 这 些 Handler 执 行 在 一 个 8 线程 的 
DefaultEventExecutorGroup 中 。 





RocketMQ 对 通信 过 程 的 另 一 个 抽象 是 Processor 和 Executor， 当 接收 
到 一 个 消息 后 ， 直 接 根据 消息 的 类 型 调用 对 应 的 Processor 和 Executor， 
把 通信 过 程 和 业务 逻辑 分 离开 来 。 我 们 通过 一 个 Broker 中 的 代码 段 来 看 
看 注册 Processor 的 过 程 ， 如 代码 清单 13-11 所 示 。 


代码 清单 13-11 注册 Processor 














public void registerProcessor() { 
SER 


* SendMessageProcessor 

*/ 
SendMessageProcessor sendProcessor = new SendMessageProcessor (this); 
sendProcessor.registerSendMessageHook(sendMessageHookList ) ; 
sendProcessor.registerConsumeMessageHook(consumeMessageHookList ); 


this.remotingServer.registerProcessor(RequestCode.SEND_MESSAGE, 
sendProcessor, this.sendMessageExecutor ); 
this.remotingServer.registerProcessor (RequestCode.SEND_MESSAGE_V2, 
sendProcessor, this.sendMessageExecutor ); 
this. remotingServer.registerProcessor (RequestCode.SEND_BATCH_MESSAGE, 
sendProcessor, this.sendMessageExecutor ); 
this.remotingServer.registerProcessor (RequestCode 
. CONSUMER_SEND_MSG_BACK, sendProcessor, this 
. sendMessageExecutor ); 





注册 Processor 示 例 代 码 段 来 自 org.apache.rocketmdq.broker 包 中 的 
BrokerController 类 ， 可 以 看 出 通过 RocketMQ 所 做 的 抽象 、 通 信人 逻辑 和 
信息 处 理 逻 辑 被 分 离开 ， 使 结构 变 得 非常 清晰 。 


13.5 本章 小 结 


本 章 介 绍 了 RocketMQ 底 层 通 信 的 实现 机 制 ， 由 于 它 是 基于 Netty 来 
实现 的 ， 所 以 首先 介绍 了 Netty 的 基础 知识 。Netty 被 用 在 很 多 开源 软件 
的 底层 通信 部 分 ，RocketMQ 以 Netty 为 基础 ， 还 实现 了 一 种 机 制 ， 把 通 
信 功 能 和 消息 处 理 功能 分 离 ， 不 同类 型 的 通信 内 容 被 抽象 成 发 送 带 有 对 
应 类 型 代码 的 Command， 同 时 根据 类 型 代码 查找 对 应 的 Processor 和 
Executor 来 执行 ， 结 构 非 常 清晰 ， 为 我 们 自己 实现 网 络 通 信 程 序 提供 了 
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